淦，上面几楼迷惑 typo 太多，自己都读着不顺，一起注释得了……
“初始化 target 的实参是个（右）值”//特指没 aliasing 的，比如直接新分配的。
“observe_ptr”→“observer_ptr”
“滥用 ad-hoc polymorphism”//指 C 的 list_item*和精神 unique_ptr<list_item>/observer_ptr<list_item>之间实质相当于存在一个莫须有的 coerce （其它的真实的 coerce 也有，比如 malloc 结果直接初始化对象指针）。而 C++实际当然也不允许这种橄榄 type safety 的屑操作。
“target 实参类型”→“target 形参类型”
“被 AT&T 汇编语法搞烦了写 shellcode ” //主要大约因为是 clang 看来不兹瓷 GAS 的.intel_syntax 。
“更多的 GNU 扩展等魔法” //主要就是 statement expression ，或者^block 之类（没试过）。
“expression statement”→ “statement expression”
“ bitseg”→“bit field”//刚好看某些 patent 上头手滑了……
“lwn.net/Articles/750306”→“lwn.net/Articles/749064”//其实前者也通，但得 C++20 。

* * *

@ColorfulBoar #29
你这 list_head 扫一眼就能让人盲猜是国内流行的数据结构书的流毒……

@GeruzoniAnsasu 节点(node)!=结点(knot)，谢谢。
所谓的不好写其实是逻辑混乱的结果。
因为原则上指向节点的指针就只是个表示节点的指针，整个链表本来就不是节点的同义词，原则上继续使用节点指针指代就是个不应当被依赖而容易引起理解混乱的实现细节，至少也应该用类型别名屏蔽掉。
（不过也有上面那个渡劫失败搞得正常的 list_node*也被混着当成了 list_head 的反面教材了。）
但 typedef/using 其实是治标不治本，因为不 oqaque ，不够提醒手贱的后果，多少有些自欺欺人……还不如直接套个 struct List{list_node* p;};，不要什么 head ，那就真是不同的类型了（而且还能借 TBAA 帮助优化，真乱转会被 strict aliasing 寄掉），在所有权上也更清晰（有效避免 Rust n00b 想不清楚链表怎么糊综合征）。实际上现在像样的实现也都是这么干的，并没什么“教科书写法”不同的争议，看所谓的数据结构书反而是被坑了，还不如直接扒拉实用的源码（暴论）。
设计上还有值的注意的一点，就是大多数需要链表的情形其实仅仅是需要抽象数据结构的一些渐进特性（比如 O(1) splice ；题外话，如果没 splice 或者防止 invalidation ，基本就不该用什么链表），因此不要求知道真正意义上的端节点，所以可以实现成环形列表（如 libstdc++的 std::list ），这样这里就更不需要纠结 null 怎么处理了。（代价是 list 不能 trivially relocatable ，不过保守估计 99%以上的 C/C++用户从来都不会想到这个问题，反正被坑的优化空间本来也用不上，C++26 （？）前八成不用纠结。）

……上面一堆 typo ，先不改了。
@cnbatch ({}) 这 expression statement 这哪里不是 GNU 扩展了（亏上面我还想故意省略掉无关紧要的话题……）……

其实这里的扩展，不管是({})还是__typeof ，直接换 C 艹就都不用扩展了。但是 C 艹就不兴这套。
说白了，container_of 和 offsetof 这种直接对语言提供了 static layout 的 ABI 限制的特性，与其说是信任程序员，还不如说是嘲笑程序员对可移植性需求的坚持没有 13 数。（既然都能假定 layout 全静态确定了，struct 咋就没个像样的通用写法，还得 bitseg 和-mxxx 敲捣呢？）
当然，不是说没有就好哪去。C 艹的 non-standard layout 抓瞎的问题更加说明了半吊子（依赖 non-standard layout 随随便便 UB ，实现又都不愿意扔掉 ABI compat ）。但这和滥用 layout 的假设是两回事。

其实一看有人拿 kernel 里的#define 和__typeof 当例子，我就会想起来 C 艹好歹没这种程度的问题：
lwn.net/Articles/750306
什么相信程序员，明明就是语言设计无（废）能（物）罢了……

另外 FreeBSD 把这种功能的代码放这个位置，说明全局工程质量上挺烂的……（虽然局部往往不如 Linux 辣眼睛。）

@icyalala C 真不适合什么 performance freak 。反正一要可移植性，freak 起来就等着暴死好了。
其实一般用户在这里能做的撑死也就是看看汇编慢慢试罢了，远远不到 freak 的程度。（见过被 AT&T 汇编语法搞烦了写 shellcode 的，这也算不上多 freak 。真 freak 就去自己糊 code generator 去了，比如 Chez 那种故意踹开汇编器的。）
我日常大抵也算不上；然鹅殊不知我无中生有插几个[&] () __attribute__((flatten)) {}（当然，C 这里到现在还是得依赖更多的 GNU 扩展等魔法）就极有可能随随便便爆杀你死活调半天甚至自己糊__asm__的代码。
当然，对我来说，典型下场是（因为能优化的解空间太大剪枝困难）编译时间比改代码时间多若干倍（虽然我也可以在此期间 review paper 或者补番），以及最近升级 GCC 12 生成烂了的代码还得傻乎乎 bisect 多加__attribute__((optimize("no-tree-pta")))（要么全局-fdisable-tree-einline ，代价太大）之类拖延工时的 hack 。不过没 ICE 就谢天谢地了。

（另外一个感想也就是 CS 101 还在教这种东西啊……这哪 CS 了。看来大部分网红课跟以前的 MIT 6.001 这样的经典的差距真不只是一个层次的。）

懒得看视频，不过看原文描述，这个 taste 就很烂。
（这很正常，从 Linus Torvalds 这些年来干的活看本质是个 PM ，从不用指望 coding 水平多高就是了。）

对合格的 C coder 来讲，应该能看出，这里的烂首先不是代码上的，而是功能描述上的，其次是 API 设计；实现是之后的问题。
具体问题首先在于，就常识而言，remove 在这类上下文中说的是从一个数据结构中移除一个元素，同时 [维持资源不泄露这个最低要求的不变量] 的操作。
这里的 API 没附加说明，就说明违反了这个通用常识，这就是 teste 最明显烂的地方。

就这个 API 实际上做的事来 [逆向] 出要求，那么更应确信名字就是错的：这里就应该叫 detach_node 而不是 remove 什么东西。如果真是 remove ，原则上这里的 API 就还应该负责节点的释放。但是这里是上下文不足的——谁知道是要用 free 还是什么分配器还是 no-op （ intrusive list ）？
不管是没有纠正这个低级设计缺陷去瞎改实现，还是要读者察觉味道不对、瞎猜需要解决的是什么问题（不过这点也可能是因为我懒得看视频里的上下文关系），整个过程在方法论意义上都是从头就 low 完了的，哪来的 taste ？

退一步讲，如果确信不需要释放资源，那么把名字改对以后，这个 API 的签名仍然很 low 。
注意，不要试图狡辩用户 [应该] 知道 target 对应的实际参数就应该能自己能处理资源——这是 C 用户中流行的、常见的、自作聪明的、典型的烂 taste 。
这种情况下，初始化 target 的实参调用前是 non-owning 的，结果调用后就 owning 了。如果没有显式说明，这属于影响 use sites 的重大接口信息遗漏。这种类型系统上检查不到的小把戏直接就能让任何负责理解清楚你要做什么的读者血压升高。
尤其愚蠢的是，这无谓地破坏了资源所有权的不变量。如果初始化 target 的实参是个（右）值，那么直接就漏了。对敢于写这种代码的用户来讲，众所周知，C 完全允许这样做且不经过复杂的指针分析，别指望静态能够发现问题。
借用 C 艹写法，真正能描述这坨逻辑干了什么的 target 实参类型至少应该是 variant<unique_ptr<list_item>, observe_ptr<list_item>>，一目了然地废话多；用 PL 话术来讲，这是滥用 ad-hoc polymorphism 。和滥用出参类似但远远更欠揍的那种。
只不过不幸的是，C 在表达清楚这些问题上的能力非常捉急（以至于我还得借用 C 艹这种半吊子），C 用户又特别喜欢拿因为表达力不足而被迫擦除类型了的中间实现来代替本来应有的正确 API 设计，这种烂 taste 导致垃圾 API 浑水摸鱼地混入了产品代码里。
而要实现“正确”的 detach ，结果一般就应该是返回值。

……于是，C 水平不足的用户的实现上的小聪明，还用得着多婊么？
如果看不出来问题或者死活没思路怎么改对，说明就没怎么会 C （毕竟怎么避免这种基本的坑是会用 C 的刚需），建议重新学习 C 。还是不行，那大概率说明你不配享受 C 的所谓信（偷）任（懒）程（没）序（特）员（性）的特色，换个能强迫你把设计搞对路的语言，回炉重造。

@walpurgis WSL 不是这个原因而产生的，它的前身是意图在 Windows 上原生运行 Android app ，但因为种种原因黄了（很久之后 Win11 上 WOA 才被支持）。
反过来，用你的逻辑，也说不通为什么微软仍然花更大的力气支持 VS （不是 VSC ）这种根本就是 Windows-only 的开发环境——注意是持续投入资源推动大量的功能性更新，而不仅仅是维持可用。

可以默认用 WSL 。
嫌弃虚拟机麻烦（比如 IP 地址莫名其妙啦……），就 WSL1 （ WSL2 本质就是个 HyperV 虚拟机实例），虽然有些限制，大多数还算能用。
例外情形：
若你需要开发 Linux 内核模块本机调试之类，那当然没办法；
用 fuse 之类也可能比较麻烦；
偶尔会有些系统调用实现残缺不可用；
不要指望 systemd 之类的东西完整可用（同等层次上依赖系统实现细节的还有 nix 等）；
GUI 多少比原生 Win32 麻烦且可能有无解的细节问题（例如输入法之类），性能可能也不咋地（ WSLg 需要 Win11+WSL2 ），但 VcXsrv 跑个别应用基本上够用；
其它情况下，和原生 Linux 的差异是否能被容忍，取决于你自身对环境的理解（觉得不保险嫌弃麻烦那还是虚拟机了）。

如果要更原生的体验，用 MSYS2+MinGW 。
警告（相对 WSL ）：原生 Win32 的构建性能会普遍降低；
小文件 I/O 性能会极其感人；
即便排除 I/O 问题，也不要指望 node.js 之类的运行时的表现不会明显变差；
同时，可能处理一些表面上容易遗漏，实际 Win32 特有的屑问题，大多是关于文件系统的：
Win32 的默认机制导致打开程序不能删除，这有时候很欠揍；
默认创建符号链接可能需要管理员权限，需要组策略变通；
Win32 不支持无视 AUX 这样的 DOS 保留文件名（但 MSYS 的工具能提供一些变通）；
可能必须需要 fsutil 单独设置大小写兼容。

如果你要继续完全原生地使用 Win32 ，那么基本不会有更好的体验（以上 WSL 解决了的 Win32 问题会继续存在），并且有些问题是无解的。

@cmdOptionKana 这篇文章有些是很扯蛋的，或者至少是过时了（即便考虑原文时间无视 WSL ）。

像工具方面：
很多都是 Win32 自己残废，而不是命令行；
Win32 的残废如果不是需要自己积极变通，是可以改用现有工具在 Windows 上的移植而无视的；
如 git 的不好用，大多是因为 git 自身而不是 Windows 上的实现（除了一些 I/O 性能问题）。

在如，第五点几乎全是在 FUD ，不知道是在黑 Windows 还是黑 Linux 。

你需要 hg incoming 类似的东西？
逻辑上还是少不了类似 fetch 的下载一些元数据的步骤，不过在明确只考虑这类需求（而不必然是之后紧接着会 fetch ）时，确实至少会比 fetch 节约流量和带宽。
但是 2202 了，git 连 clone 的断点续传都不兹瓷，大约你也不需要指望这种东西了。

我没法给出可靠的具体建议，不过需要指出，光是想搞清楚什么算是“前”，对 GUI 开发者来讲都经常算是不切实际的奢望。从现状看，“过时”在这个领域中不应该是需要被优先考虑的缺陷（否则很容易发现新的都是一出生就更过时的）。
cf. https://v2ex.com/t/852363#r_11667402

目的上……现状大致如此。如 vscode 这样的编辑器，其实用浏览器代替，也不会比 ssh 过去再用麻烦（即便编辑本地文件逻辑上比较感人）。
创业公司实际比较不好说，在 Electron 能胜任的前提下，选型主要倒不如看老板 /CTO 是不是有前端背景。如果直接有整个前端团队那么也还算是很香的（但是也别指望能做到 vscode 的程度）。

另外，我始终认为有必要把 C++/Rust 这些和所有有 GC 的方案区分，不是因为 C++之类的难度如何，而是默认情形的正确性——很大程度上，写 GUI 基本就是从头开始写 bug 。
有 GC 的语言实际上是假定资源默认推迟而没有可观察行为，这对 GUI 根本矛盾，因为 GUI 最基本的需求之一是对响应有要求（应用级的实时性），而程序内部却默认对此几乎完全放弃保证。一些像基于.NET 少数做的还能看的方案，是在框架层次上就死命优化和工具等周边生态配合的结果；相比之下，Electron 之类（浏览器实现）就无能为力或者干脆弃疗，锅都甩应用开发上了。即便是.NET 的程度，还是在鼓励默认和根本需求相违背的写法。
实际上 C++也算不上好哪去，因为 C++同样没能力显式区分描述可观察行为（无非是多了个 volatile ，没有 effect handler 之类），同样没有强制实时性的原生支持，实质上也缺少鼓励异步的写法（新手基本是写出来发现交互寄了点不动，才回去改），因此同样免不了在运行时外面套壳（指应用卡翔以后系统给出无响应界面替代而不是继续阻塞）。只是没默认 GC ，而是要求用户自己在详细设计时搞清楚所有权关系，避免默认就写出看上去顶用但实际就是一坨原生 bug 的玩意儿，已经相对算是进步了（反过来说，直接用默认 GC 的语言写 GUI ，就是明确的退步）。
照例继续多黑弃疗党的代表一下：github.com/dart-lang/language/issues/490 。

……看到这标题一瞬反应是 BABA 股价咋那么高了（笑哭.jpg ）

@learningman 1. 不要看古董和野鸡教材误导浪费时间，就开发个普通的 GUI ，C++有的那些烂门槛，实际怕还不如 Qt 的非标准工具搞出来的破事多。
你倒不如说 C++开发 UI 效率整体还是低。这个尽管近些年有改善，但从没彻底解决；想跟前端比差远了。
2. Qt 的平台特定的代码，一部分是故意的（因为不是每个平台都能支持相同的功能），少部分是太旮旯，少人关心。
相比之下 Electron 更统一，但是真需要平台特定的功能，基本全部要你自己搞定。所以这个比较不公平。
不过这部分的选型问题我中立，因为 Qt 的 C++用起来算是比较恶心的，UI 以外的部分都不见得比无视 Qt ，全部自己搞定方便，所以没明显优势。
3. 那按上面我提的，当我没说。
4. 这有点强词夺理。即便是依赖 Qt 的应用，也可以要用户自己源码编译或者可以自带二进制文件，但为什么非得费力不讨好？体验明显差。
注意 Qt 的二进制文件基本上是 native 方案里最大的、跟部署个浏览器没差多少、基本上同样被鄙视的那类（特别是 Windows 上基础设施支持薄弱，装了也很难复用，到处复制 dll 算是传统艺能了），与其说兼容性，还不如说是在安装体验上拉到了几乎跟自带浏览器的应用同等低劣的水平，这点更容易让用户感知到。
就算硬盘空间不值钱，流量和用户的时间仍然经常比你想象中的更值钱。
Electron 在这里选择余地更少所以仍然更差。

@encro 大部分“桌面”应用，指的是传统上 UI 和功能集合在一个软件产品的应用。即便如此，有的（如 Office ）也在往 Web 跑，回到桌面（至少在现有桌面开发体验极大改善前）不是主要趋势。
如果一个产品的服务端的重要性占比例太大并且 Web 实现够用，那么其实并不太有提供桌面客户端的需要。毕竟桌面浏览器现在整体能做到的比移动端强得多，用户习惯也普遍不一样，犯不着非得单独多给个 app 加深粘性。
既然已经部署成云服务了，顺手能写个 Web 的，干嘛非得再多此一举呢？多少有些凑 KPI 的味道了。

这看来是详细设计评审没做到位，或者根本就没怎么做。如果小明和小红清楚地知道对方在干啥，这种共用函数一般不会是实现了一半才发现，要么就是发现了也少到能容忍复制粘贴实现的程度。（还有种情况：A 和 B 大到设计时没法一次性做到那么细，直接扔给单人负责却又不及时同步以至于根本没法及时注意到别人做了啥，但那样是项目计划就离谱了。）
正常做法是知道共用函数后开 upstream feature branch 或者并行开 common feature branch （极端情况下嫌弃 feature 少 branch 多也可以扔 master 里，如果项目规则允许）优先实现，然后直接基于这个 branch 或者包含这个 branch 修订的某个 tag 开 A 和 B branch 。
但既然开发了一半，如果不像停工重建这个流程的话，就 cherry-pick+rebase 补救吧。是不是 squash 看约定，改动太大可能会很麻烦。

@encro 个别应用用 Electron 可以，带上桌面环境或者大型 GUI 应用的，Electron 基本没戏，并且不大会随着时间推移而改善——这是我先前表明的基本观点。

其实桌面跨平台开发的问题挺经的了，包括 Electron 和 Qt 在内的话题讨论过很多次。在 v2ex.com/t/841554#r_11485005 这里就有很多细节。

老实说，Qt 的问题其实非常大，纯属矮子里拔高个。关键是如果想要跨平台，就没几个选择。Qt 是现有 GUI 框架方案中功能、性能、工具、社区支持、案例资源……等方面整体均衡考虑下最完善成熟的一个。虽然设计有很多挑战忍耐力的小问题，成本也算不上很低，但是并没有像 Electron 那么显著、容易在一大类项目中一票否决的缺陷（像上面讨论的问题中 OP 直接就不接受 Electron ）；也没有贸然采用不那么流行的新的方案的风险。

基本上现实会考虑 Electron 的主要是两类：从现有前端项目迁移；有相对比较多的前端开发人员，但是别的人员不充裕。其它情况，Electron 很难成为首选项。特别地，想要完全解决各种没法预期的问题，和自己维护一整个浏览器的技术难度差不太多，不像其它很多方案实在不行自己魔改一下也行。相对改浏览器运行时，C++的原生框架就算需要魔改定制，都不算多困难了。

Qt 不是不能用样式，QML 这种照抄前端的方案直接就能 CSS 定制。不过我个人对那套不太感冒（开发体验也不会有 Web 成熟）。
MVVM 不是万金油，特别是有一部分典型的桌面应用不那么合适。若干年前微软发明 MVVM 的就写过一些技术文章讨论里面的缺陷，记得大致意思是比 MVC/MVP 等都更重量级，性能必须有损失（当然比起 Electron 、Flutter 之流嘛基本可以忽略），而好处基本体现不出来。不过这是相对比较细节的问题。Qt 在这个架构模式这个层次上的设计也确实不咋地（相对 WPF 等），而且要真用上 MVVM ，（就 Qt 框架设计者的 C++水平看）怕是出来的 API 只会更难看和难用。
Python 绑定用起来是一时爽，但如果要自己重现里面的技术，做框架级别的开发就蛋疼了。（最近几个月我还在头疼怎么搞出个类似 Shiboken 的东西，同时避免对 Python 的依赖。）

（其实我是有本事手糊跨平台框架，但是我没本事保证足够的人力出完善的解决方案，所以就忍了。）

其它技术，像 GTK+和 wx 这样同属 native 的，资源比 Qt 缩水多了（也许一般开发者体验到的最大的好处就仅仅是不用 Qt 恶心的 C++ moc ）。而像 Flutter 之类基于动态 GC 语言的框架，大多类似 Electron ，根本上不能指望克服类似的缺陷，并且显然还没 Electron 资源丰富。
微软的一些东西做得相对中庸一点，但你没法确保啥时候微软自己怂了就跟 WPF 一样丢下转进跑路了，留下社区收拾不了的鸡肋烂摊子。再者，Windows 自己 GUI 风格带着开发体验碎片了一地，也很难让现在的桌面开发者对微软重拾信心。并且像 WinUI 这种直接扔下旧版 Windows 不管的作风（明明就算加个支持也不是很难就是不干），很多传统开发者是不买账的。
所以我不觉得这些方案有更大的发展空间能一桶浆糊。
考虑这些新的方案就没有一个打算（能不能先另说）同时解决以前的主要痛点，反倒要超额投入精力才能熟练，学到的东西复用还困难，这也太微软了。因此，在具体刚需前没什么上车的必要。

@learningman 牛头不对马嘴……你看看你在这里的几个回复有几个是正面回答了他人对你的说法的疑问的？
我对“企业级”什么的就没兴趣（高性能？要不是欺负的是 Electron ，啊呸……），你看看你说的是个啥？
承认 Electron 在桌面基本没生态（除非你好意思把 Web 硬是直接算成 Electron ），偶尔有个能的应用基本都是自带运行时而没有现成的系统基础设施的广泛支持，有这么难么？

所谓“从其他平台迁移”，你这个其他平台，不就是 Web ？要是有不兼容的 native 组件需要移植，也和 Electron 自己没什么关系，不管是优点还是缺点。当然你非得把一个系统上的 Electron 当作一个平台如蜜传如蜜，那当我没说。

相对地，一大票 Qt 软件直接就是原生开发好的，一样不用迁移，无非是重新构建一次，一样能做到所谓的几乎 0 成本。区别只是 Qt 故意开发不可移植的应用仍然更容易。但就这里的问题，本来用 Qt 就是为了跨平台，谁那么空哪壶不开提哪壶？所以你说的还是莫名其妙。

@encro 基本上多数人都会考虑的上规模的，也就一个死命优化的 vscode 还能看了，即便如此也只是能用，并不相对非 Electron 实现的竞品比起来明确占优势。没那么上进的同类货色……比如看看 Atom ，坟头草多高了？
倒不是看不上 Electron ，说实话里面的黑科技还是挺多的。
然鹅 Electron 自身的技术弱点决定了要实现能实用的规模产品，必须投入巨量的资源，而且撑死也就是“比较能用”的范畴。所以除了迁移 Web 应用，对大多数开发者基本也只适合试验做原型。而做原型的选择未来也只会更多，固有问题解决又极其困难，所以注定前景不会好哪去。

@XiLingHost Unity 在跨桌面这个坎上不成气候。
真算上，那么跨 Windows 桌面和 XBox 呢……是一个概念么。

@learningman 别的小儿科不提，Qt 有被拿来实现 KDE ，Electron 有个啥同等的玩意儿呢？
或者你更愿意嗦 GTK+？

半斤八两？你直说吧，就是欺负人家在有选择的前提下懒得写啰嗦业务代码罢了。真写得写不出来明显两码事好不。
比如就实现操作系统这个业务，真有人汇编写出来比你 C 写得啰嗦得多，你还能咋地，批判不够半斤八两？（别忘了 C 之前基本都用汇编写操作系统。）


@Macolor21
> Java 不断被喷的原因就是，每一行代码都必须清晰的表达用什么类型，做了什么事情，看起来像个啰嗦老太婆，但实际上每一行代码都特别清晰。

每一行代码都必须清晰的表达用什么类型 ×
清晰地自以为是 √

比如 Java 10 之前死皮赖脸不肯加 var ，因为一些人自以为没声明显式类型就是“不够清晰”（甚至加了之后还有人想反攻倒算的）。
殊不知有的场景的详细设计就明确要求这里对具体类型进行关注点分离，强调符合设计的类型是满足某特定约束的“任意一种”，而 Java 的类型系统甚至还没能力描述清楚 sum type ；还要求写清楚具体类型那就是妥妥地扯可修改性后腿，反过来毒害设计。
这里被喷的主力就是类似这样的脑补他人合理实际需求不存在，又不懂替代解决方法的自以为是的用户。在某些领域，这些用户被称为民科。
（当 Benjamin C. Pierce 都在反思 more typed 是不是 more expressive 的时候，又哪来这些民科误导舆论的空间呢？）

> 可能一部分人为了显得自己与众不同，高人一等，所以它们倾向于学习成本更高，看起来更简练的语言。

不巧的是，Java 用户中，这类人相对别的语言的用户特别多。于是对剩下的不少用户来讲，与其一个个纠正，还不如先润为敬，反正就是 JVM 生态也有不少别的替代。这样，黑起来就更容易了，不怕误伤友军。
从一开始就不依赖 Java 的旁观者来看，你们这点破事还是省省的好。非得站队，那自然是优先消灭妄图按闹分配的老古董的，免得还有来不及补课基础不牢靠的死硬分子找到借口反智，故意拎不清楚到底是谁在与众不同。——麻烦记住，没人逼你编程来搅乱市场。

提 Rust 的，我就有点好奇，满口 unwrap 口味怎么样……

@cmdOptionKana 别尬黑，http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0534r3.pdf 就没落地，没法用可移植的 C++取得合理的实现。
（虽然你提到的几个语言一样都没这本事，反倒这玩意儿在 boost 里现成有还算能用的实现。）
和 OP 的需求相关的后果是，没有在语言中确保提供类似可移植的功能，就不可能把一般意义的异常处理实现为语法糖，原则上必须原生。（虽然 C++异常一坨 ABI 屑问题，虽然大多数语言一样做不到，以及做得到的语言多数同时自带原生异常，等等……不过都是另外的问题了。）

另外跟 OP 不同的是，我没有发现重启特定软件就一定能医好虚化的问题，不过退出 mstsc 重新进入（只要登得进去）一开始一定没这问题（但之后多少时间再出现问题就不好说了）。