背景

c++一直以来使用c风格#include头文件方式引入依赖，而#include的方式存在诸多问题长期被程序猿吐槽，细数下来，这些问题包括不只限于：

include方式存在的问题

拖慢编译速度

这也是标准委员会引入module的主要原因，#include只是把头文件贴过来将代码段变成一个拥有完整上下文定义的整体，编译时就会出现引用的某个代码段在多个编译单元内重复编译然后链接时再合并的过程，重复编译自然会拖慢效率。

三年一度的C++标准文章这回在不到两年的时间点就开始了（请想象自嘲口吻），这次是一个持续更新形式，主要由于本就是利用业余时间写的，近两年家里又多了个小淘气，闲暇时间就越发少了，尽早更新完吧。这次看到中文维基百科上C++标准的条目内容有所缺失，所以同时还会持续更新这个页面维基百科 C++20，当然维基百科上不能像这篇文章里一样这么多废话。😂

新的语言特性

特性测试宏

或称功能特性测试，在c++标准中增加了预处理宏用以检测当前的c++功能支持情况，以往这些预处理都是根据编译器版本宏来控制，现在标准中增加了这些宏。
这些宏包含：

1. 属性检测宏__has_cpp_attribute，形式是宏函数内传递属性token：

写这篇的背景是当前很多shell都会有git prompt脚本，即对当前git仓库分支、改动情况的提示。
git分支命令的执行通常不会占用太多时间，但是改动情况的命令如git status或者简短版本的git status --porcelain则不然，特别是当仓库项目很大时，当你有以下我的使用场景时则更为糟糕。目前我个人的开发环境是windows+wsl，习惯上我会在win上通过git for windows的版本clone代码，然后在wsl里访问编辑，在这种场景下你会发现在wsl中的git status命令执行时间更长（这里我没深究其原因），特别是当你每敲一行命令shell都会去执行git status就更加恼人。
以下为个人的折腾记录，“可能”会不断更新不同shell的情况：

总体结构

variant

首先是variant的结构，variant的模板声明长这样：

1
2
3
4
5
6
7
8
9
10
11
12

template<typename... _Types>
  class variant
  : private __detail::__variant::_Variant_base<_Types...>,
    private _Enable_default_constructor<
      __detail::__variant::_Traits<_Types...>::_S_default_ctor,
        variant<_Types...>>,
    private _Enable_copy_move<
      __detail::__variant::_Traits<_Types...>::_S_copy_ctor,
      __detail::__variant::_Traits<_Types...>::_S_copy_assign,
      __detail::__variant::_Traits<_Types...>::_S_move_ctor,
      __detail::__variant::_Traits<_Types...>::_S_move_assign,
      variant<_Types...>>

_Enable_copy_move在上一篇optional解析中解释了，这里不同之处在于要考察variant的模板参数包内多个类型的可复制性、可移动性，如果其中某个类型不可复制或不可移动，那么variant亦不可复制或不可移动。
_Enable_default_constructor为用于生成默认构造的helper模板，代码长这样：

std::optional是17标准中增加的管理可选值的类模板，以往经验中如果某个函数的返回值可能失败，如何判断这个失败值和传递这个失败值都需要些额外的手段，optional的出现则很好的解决了这个问题。以下是gcc13版本中std::optional源码的个人解析：

std::optional实现内各类型关系

optional

首先是optional模板声明及内部别名：