@wzzzx joinable()只是检测这个 std::thread object 是不是依然持有一个进程而已别的啥都没干，或许你想问的是为什么 std::thread 的 destructor 这么奇怪……当然不管想问的是啥，不管把标准还是实现重复一遍肯定都没意思，你一定想听个刺激的，所以让我恶意转述一下史官 Bjarne Stroustrup 的说法：我们当年也不想这样，但活在 [世界上只有 C 语言 + POSIX 的 P 意思是 portable] 这个梦里的 C 标准委员会因为 C 里面没有 RAII / POSIX 天生残疾就以为别人也不行，强烈反对我们干人事（这是唯一一份 C 标准委员会发给 C++标准委员会的正式通知），那就别怪我们摆烂了。

@guang19 这……你不会以为 printf 是直接写屏幕上的所以不显示等于没执行吧？你这个在当前 scope 结束的时候 t1 仍然是 joinable 的，所以 destructor 会调用 std::terminate()，然后 stdout 的缓冲区里面的东西就直接被扔了所以看起来什么都没有。你关了 buffer 或者手动刷新一下就能看出来了。

@guang19 你这也太离谱了……谁教你的 join/detach 之后才会执行？真心建议重新学习一下标准库里面的 thread

constructor:
Effects: The new thread of execution executes...
Synchronization: The completion of the invocation of the constructor synchronizes with the beginning
of the invocation of the copy of f.

void join();
Effects: Blocks until the thread represented by *this has completed.
Synchronization: The completion of the thread represented by *this synchronizes with (6.9.2) the
corresponding successful join() return...

void detach();
Effects: The thread represented by *this continues execution without the calling thread blocking.
When detach() returns, *this no longer represents the possibly continuing thread of execution...

以前都默认 Mac 不适合玩游戏，最多努努力把不能玩游戏说成优点（比如楼上好像就有），哪像现在不知道哪来的一帮 CPU 和 GPU 都分不清的（但凡能分清也不至于在测 GPU 性能的时候扯什么 Rosetta 转译）拼命证明 M1 吊打 3080 & 帧数高说明性能好帧数低说明游戏优化不行的。
拿游戏出来测 GPU 性能已经是够给面子的了，毕竟游戏引擎的任务比较复杂很容易处在一个鬼知道瓶颈在哪的状态，很多时候不能完全发挥硬件性能，「优化」余地也比较大。不然非要嘴硬说游戏不是生产力那就去找个同时支持 CUDA/OptiX 并声称适配了 M1 的渲染器，比如足够新（ 3.1 以后）的 Blender 里面的那个，去测测渲染速度会发现结果更尴尬（之所是说「声称」，是因为结果过于尴尬以至于肯定很多人觉得是因为没优化好不算真正支持了 M1 ）。如果你发现自己没找到 M1 Ultra ，在确定筛选条件没设错的情况下多往后面翻翻，大概在 RTX 3050 Laptop 这个水平。

---

@crayygy GPU 的 G 是 graphics ，不是 gay video ，谢谢……视频相关的硬件加速是专用电路做的，只在显卡上面占一小块。没啥特好看的图（比如 die shot 上直接标出来哪块是的），用这个凑合着感受一下吧
https://i.imgur.com/gFqpyPk.png

@cassyfar 目测这个版本就没做……你手工搜索一下把所有包含 account 和 password 的地方塞个 countrycode 进去就能凑合着用了（虽然对我来说好像只有来自 bilibili 的能下下来，然后上传一定失败，约等于不可用，如果你不在国内我猜也是这个结果

@vcfghtyjc C++本来就不是一次性精心设计出来的语言，再把那些兼容 C 的东西放进来之后就更混乱邪恶了。这种时候做一件事情会有多种方式，其中的一些虽然凑合着能用编译器不会干死你但精神上不太正确 /属于历史残留问题（比如某些 best practices 里面三番五次提醒过不要用的），所以 C++里某种写法语义正确完全不代表应该接着用它们，强求一致性更是没意义与不可能的。如果想写一个优美点的语言，你就不能把所有语法同等对待，必须自己裁剪一部分出来顺带着对一些旧东西进行新的解读，而做这些事情的依据不是 C++内部能确定的，得由来自外部的知识确定，这大概是我想强调哪个（至少精神上）更「正确」的原因。
至于学习门槛……现在 C++的学习 /教学上问题当然非常大，我觉得最麻的还是初学者刚上来基本上是在大量过时 /误导性的材料里面游泳，而不是符不符合直觉这种事情（毕竟一般人的直觉很多是错的，如果一个人直觉比较准的话那它大概自己也知道咋学了不太容易被各种坑人的东西整蛊到）。

关于你具体的问题……我觉得不应该把 string literal 看成是某种老式的 std::string ，它（作为指向一段 char const 的 handle ）更像是个扭曲的 std::string_view ，这下子二者都不支持 operator+了（ view 对“运算”不封闭：把两个 view 拼在一起并不能得到一个新的 view ），是不是顺眼一点了？
（当然这是种重新解读后的结果，毕竟别说刚整出(C) string literal 的时候还没有 string_view 了，好像你看的这书因为有点老里面也没有它……）

@vcfghtyjc 一般加法暗示运算是可交换的，乘法不一定保证交换，矩阵乘法总还是见过的吧？另外把 s 和 t 拼接起来的串不就是 st 么，反而 s+t 看着怪怪的，而且任何一个稍微正经一点讲字符串的地方（定义了什么是 alphabet 什么是 string 的）应该也都是用前面的记号表示 concatenaion 。再换个思路，考虑两个字符串的集合 A ，B ，那一般情况下 A 里面的串 a 和 B 里面的串 b 拼起来的所有可能情况也更接近 A 和 B 的笛卡尔积（模掉一点重复的情况）而不是不交并（那个是集合的加法）（不理解 universal property 可以直接数集合里面包含多少个元素也可以理解为什么前者叫乘法后者叫加法）。所以不管怎么想都是乘法更合适，至于为什么这么多语言选择用加号……懒得查始作俑者是谁了，剩下的怕不是互相抄了抄压根就没过脑子，不然总得说出来一个把 operator*保留下来的合理用处吧？

string concatenation 构成一个 nonabelian semigroup ，用加法完全不符合直觉，还不如写成"hello" "world"这样当成是省略了乘号的乘法。
另外要不要考虑一下放过可怜的 operator ，多跟 format 玩玩？

fact check 的正确翻译是「辟谣」，后者在中文世界是什么意思，前者在英文世界就是什么意思。具体是哪个意思你可以自己选，但两者是一致的。
考虑到肯定有很多居住在南极熊语世界的真外宾，我再多解释一下：一个东西给自己名字里面加上 fact 并不会让它变得更真实或者更不真实，做出正确判断所需要的也从来不是什么 fact check 意识，在新闻细节真假上进行努力的唯一用处是任凭自己内心的隐秘诉求把它剪裁成一种武器。正如看一万本科普书 /杂志也不能在科学上做出任何有效判断一样，在这类新闻上再怎么精耕细作也不能帮你做出更明智的选择（解决方案也和前者一样）。

PS：虽然上面已经说完所有我想说的了，并且包括南极熊在内的每一句我都是认真写的，但还可以再通俗+难听一点：如果你必须靠什么破 fact check 才能知道新闻不是都是真的，那也别谈什么 who fact-checks the fact-checkers 了，还是直接宣判没救了比较合适……

真正的儿童可能会觉得 B 站干的唯一一件人事就是没整什么破儿童动画来恶心人：）

为什么跟 ru 沾边的都会进水深火热？为什么楼上小孩砸地板比 GitHub 干了什么更“技术”？
为什么明明被墙了敏感词列表反而比很多国内论坛都长？