虽然有了 auto 关键字，但是用起来还是需要 trailing return type 声明。
可以省略尾部声明（以下两种写法都是要 C++14 才能支持）：
auto f() { return 42; } // #1
auto f() -> auto { return 42; } // #2，相当于 #1
Note
例外：在 C++23 explicit object parameter 可用之前，构造递归 lambda 时需要显式声明返回值类型，否则无法成功推导（或者先用 function 模板类存储起来，类型也就能从 function 中推导）。
同时 C++14 还支持 generic lambda，即使用 auto 作为函数参数的类型。
$() 和 ${}
除了 $ 之外，$() 和 ${} 都是 make 替换变量的语法。但是 ${} 还能被某些 shell（比如 bash）继续替换。
此外，它们也能调用 make 提供的命令，比如字符串替换、过滤和调用 shell。
* 参数
是因为 make 传参的时候将引号去掉了，导致星号又被 shell 解释了一次（我用的 MSYS2）。
$ cat Makefile
all:
echo \'*\'
$ make
echo \'*\'
'*'
$ nvim Makefile
$ cat Makefile
all:
echo '*'
$ make
echo '*'
Makefile
./ 来表示路径，不要使用 .\。（但是这样 cmd 解释不了，得用 bash 才行）.exe 后缀。noexcept 有几个用法：
noexcept(true)。// whether foo is declared noexcept depends on if the expression
// T() will throw any exceptions
template<class T>
void foo() noexcept(noexcept(T())) {}
void bar() noexcept(true) {}
void baz() noexcept { throw 42; } // noexcept is the same as noexcept(true)
int main()
{
foo<int>(); // noexcept(noexcept(int())) => noexcept(true), so this is fine
bar(); // fine
baz(); // compiles, but at runtime this calls std::terminate
}
C++17 已经禁用 throw 的显式异常声明。（被称为 Dynamic exception specification）
现在已经没有 Segment 概念，并发系数不生效。能支持高效的并发：
为了节省空间，在 Node[] 中用 hash 为负的头结点来表示该拉链处于特殊状态：树结点、转移中、预留等。
转移的时候会以槽为单位进行，如果看到槽位正在转移中，则当前线程不会去抢夺工作，除非两个线程刚好看到了同一个槽位需要转移，这时会加对象锁处理。在遍历时会按照 (hash_of_key: ph & capacity_of_old_table: n) 计算出给定位，以此来分组（理想的情况会对半分），然后用头插法生成两条新链表转移到 nextTable。
💡 这当中有个优化过程：计算 lastRun，称链表尾部一连串对应 bit 相同的结点的起始位置为 lastRun，这系列结点将会被转移到 nextTable 的相同位置，因此会直接被转移，而不会对每个结点重新用头插法插入。头插法不仅需要遍历这一系列结点，还要对每个结点申请空间。
写的时候加锁（因为要替换 array 数组的引用，而且复制的过程比较耗时，不宜自旋），读的时候不用加锁。替换的安全性由 Java volatile 保证。
CPU 内存屏障：https://sf-zhou.github.io/programming/memory_barrier.html
volatile 与内存屏障总结： https://zhuanlan.zhihu.com/p/43526907
X86-64 下仅支持一种指令重排：Store-Load ，即读操作可能会重排到写操作前面，同时不同线程的写操作并没有保证全局可见，例子见《Intel® 64 and IA-32 Architectures Software Developer’s Manual》手册 8.6.1、8.2.3.7 节。要注意的是这个问题只能用 mfence 解决，不能靠组合 sfence 和 lfence 解决。（用 sfence+lfence 组合仅可以解决重排问题，但不能解决全局可见性问题，简单理解不如视为
sfence和lfence本身也能乱序重排）
X86-64 一般情况根本不会需要使用
lfence与sfence这两个指令，除非操作 Write-Through 内存或使用 non-temporal 指令（NT 指令，属于 SSE 指令集），比如movntdq,movnti,maskmovq，这些指令也使用 Write-Through 内存策略，通常使用在图形学或视频处理，Linux 编程里就需要使用 GNC 提供的专门的函数（例子见参考资料 13：Memory part 5: What programmers can do）。
下面是 GNU 中的三种内存屏障定义方法，结合了编译器屏障和三种 CPU 屏障指令：
如果需要长时间等待，AQS 总是会将等待线程加入到队列尾部，唤醒时总是唤醒队首线程。这样做能够保证已经被睡眠的线程必定按照顺序唤醒。这样做难道不是永远都是公平锁？
不是！NonfairSync 在 tryAcquire() 时不会检查是否为队首。这意味着如果有队列之外的线程尝试获取锁（发生在刚刚调用 ReentrantLock.lock() 的阶段），可能会先于队首线程获得锁。虽然这种情况的发生非常需要巧合，但也是不公平的； FairSync 对这一巧合下的公平性做出了更高的要求。
公平和不公平的主要区别在于等待队列外的线程和等待队列上的线程之间的公平性。
只有 countDown() 被调用给定的次数后，await() 才能被唤醒。
现在对象锁不尊重虚拟线程，但是 JUC 下的锁是尊重虚拟线程的。
ThreadLocal 和虚拟线程配合的不是很好，尽管功能上 ThreadLocal 是支持虚拟线程的，但是由于虚拟线程数量众多、生命周期短，使用 ThreadLocal 时虽然保证了线程安全，却创建了大量对象——这个问题在平台线程上就不明显。JEP 429 ScopedValues (Java 20) 是为了解决这个问题的。
💡 ThreadLocal 和线程池配合的也不是很好，因此短期任务结束后，将线程放回池中之前要及时清理数据。
ScopedValue 用 where 绑定共享变量，用 call 来启动虚拟线程，这样虚拟线程及子虚拟线程能够在调用环境中通过之前捕获的键（图中为 KEY）来获取值，这里使用方式也类似于之前的 ThreadLocal 查表。于是，一些本可以共享的变量实现了共享。
本篇内容参考提案 Simpler implicit move。
隐式移动是函数返回值优化的一种，在 C++ 不同版本有不同的规则，这篇文章主要讲隐式移动，不涉及其他返回值优化的内容。
变量表达式（id-expression）指的是仅由变量名组成的表达式，比如 x 或者 (x)。虽然变量本身可能是值类型或者右值引用类型，但是变量表达式是左值。
值类别可见 Value Categories。
隐式移动使得函数可以在更多的场景用移动构造函数来构造返回对象，从而避免拷贝。但是，隐式移动通常要求编译器在特定的条件下改变返回的表达式的值类别（lvalue / rvalue），这使得一些函数表现出让人意外的语义。
Plain Old Data
https://stackoverflow.com/a/4178176
成为 POD 的条件：