@777777 张益唐：？

@dragondove 依赖 C 什么时候是担保不特别慢的下限了？ Rubinius 比 CRuby 快的理由还是尽量用 Ruby 不用 C 实现呢……因为一旦用 C 写死了就无法继续用运行时优化了。
只有非常不依赖切换互操作上下文的任务（比如纯数值计算）才能现实通过本机实现提供像样的性能基线，然而越是这种情况往往越是没理由特别去用你这胶水，所以想要强调性能改进，这种东西是历来需要淡化的，你这哪壶不开提哪壶啊。

你可以先放置 GUI 。做 CLI 工具没那么多有的没的。
这是考虑到你若不愿意接受 @dcsuibian “别写了”的建议以后的最现实合理的挣扎。

个人项目为什么非得要服务端分离？ Electron 直接本地跑不行？不要 GUI node.js 都够了。
反正你也没说优雅地运行和部署嘛（

@wxm 这跟清高毛关系。
就跟你楼下说的一样，拿到钱快乐，那就是首先因为拿到钱。拿到钱的原因就次要了。
而作为常识，大多数快乐是能让人损失钱也觉得快乐的，或者至少不需要那么在意钱了。这种快乐本质上是一种消费。
要是消费得到的快乐都不入了你法眼，快乐到只剩下赚钱，那就不是清高不清高的问题了。那是怪胎。

原则上不需要在社区版本里掺杂其它授权的材料，只要联系得到版权方就行。
但是一般至少得在你的产品宣传中说清楚提供的许可证选项，免得不明真相的社区用户看到别的其它授权的用户不遵守社区版许可证就以为是在侵权了。

@hardwork 钦定 x86_64 那一样是错的，除了上面有提到的指令是不是 atomic 得具体分析，更关键的是：编译器没义务照他脑补的情况生成代码。就算是个寄存器操作，编译器大爷爱高兴劣化代码没事多 load/store 几次，照样可以不是正确性 bug——因为几乎所有情况下，源代码和生成指令对应关系这玩意儿连 ABI 都不是。就算实际编译器很少（但不是绝对没有）蠢到没事找事，优化出这类 bug 的可能性仍然比直接生成语义错误代码的 bug 的可能性更大（就是因为这种情形更能容忍）。
主要例外就是直接怼内联汇编，编译器调用汇编器提供指令助记符和特定限制下指令对应关系的保证（但一般汇编器仍然通常不保证具体机器码的选择）。（然而谁管这叫 C++？）

@Huelse 这个是很 mmp ，但还有个非 Windows11 特供的上古遗留的更抽风的：窗口标题栏给你跑到屏幕外面去死活点不到，有的都没有任务栏能点到，甚至菜单快捷键因为被 PowerToys 占也点不了。至今 msi 安装有不小概率随机复现……搞得我专门预备了个 sizer 加了个只调整窗口位置的配置。

你这也太水了，连 MSYS2 自带一大坨不同 triple 都没说清楚。

https://github.com/FrankHB/pl-docs/blob/master/zh-CN/mingw-vs-mingw-v64.md

（还没更新 ucrt64/clang32/clang64 和接下来可能上的 mcfgthread……）

ABI……谅你折腾 ffmpeg 的，C 艹部分的稀烂玩意儿不碰就算了。但是只要够 active ，ABI breakage 照样能分分钟喂你饱：

github.com/msys2/MINGW-packages/pull/13528
github.com/msys2/MSYS2-packages/pull/3229

@fengjianxinghun 这就过于乐观和离谱了……比如光考虑讨论对象明确就不太可能扯清楚……
@PeacePeach 以前钢琴姿势怎么都不规范的时候就觉得果然是没找对键盘……
@walpurgis 你这说的什么玩意儿，不说分不清 WM_CLOSE 和 WM_QUIT ，不说关闭是退出还是最小化到托盘，explorer.exe 多窗口被你吃了？
@lysS 我就会……鼠标两年没怎么碰了。

“征信你解决？”

脊椎病，不一定是颈椎，也不一定就是因为保持固定姿势过久的单一原因。
不管哪种，最好都趁早学会躺（物理），同时不影响工作效率（以便维持医疗开销）。

切换应用的 UI 改过很多版了，以前有的也只有图标。不少用户都认为缩略图更方便。有问题也只是没有提供选项适合你的习惯。
像 ExplorerPatcher 就同时自带 Windows 11/10/NT 不同风格能选，还有一个自行实现： https://github.com/valinet/ExplorerPatcher/wiki/Simple-Window-Switcher 。

@FrankFang128 @kingcc @interim 这问题不是改过了？我这里看到的是 OP 说“我提出中文注释会导致乱码问题”，CTO 直接拒绝中文和拼音，也没说理由跟乱码有关（拒绝拼音跟乱码应该也没关系）。

@IvanLi127 这边对未经许可擅自加 emoji 的我会认真基于头脑过于简单的理由考虑打死，至少有这些理由：
(1)可能毫无原则地歧视色觉障碍者；
(2)直接就有 www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1949r7.html#all-emoji-become-excluded-instead-of-just-some 这样的 zz 不正确的破事；
(3)可能间接扰乱关注点，唆使业界一般用户普遍分不清重点，导致或者加剧 github.com/llvm/llvm-project/issues/54732 之类的问题。

@reallynyn 你太抬举巨硬了。
BOM 不是巨硬发明的，正如一般的二进制文件的文件头也不是巨硬发明的一样。

没 BOM 而产生混乱的实例是很好找，比如 VS 就不认没 BOM 的 UTF-8 。FreeImage 这种注释里直接写了非 ASCII 作者名字的在当前代码页中不认识，一打开就就呵呵了。
但对没 BOM 的“文件”的处理本来就是君子协定。说到底代码页也不是巨硬发明的。

@GeruzoniAnsasu 不说中文，倒也可能是负责给 Unicode 糊的屎擦屁股的公司。
比如纠结标识符里能给用哪些 emoji 。

钦定什么原子性的先收收味。
不说 C++所谓的 atomic operation 和 x86 TSO 之类的 reference model 和大多数没手撸过 CPU 的用户脑补（ ISA 以上某些便宜行事的“原子性”，比如 x86 下当或者不当 LOCK#是摆设倒腾 bus 还是 cache 都可能得单独讨论）这三者之间实质上两两不同，OP 都还没说具体环境呢，给个 6502 之类的不得齁死？
这里能脑补多少所谓的原子性都提供不了什么保证。（退一步讲，就是要对锁 PTSD ，用 std::atomic<int>都还得纠结一下是不是有 std::atomic<int>::is_lock_free 呢……）

扯具体实现就不要拎过来当什么 C/C++问题。
C/C++？不务正业无中生有叠 UB 甲还嘴硬浪费别人时间拖进度，直接扣绩效。

www.eel.is/c++draft/intro.multithread#intro.races
连 int 有没什么脸特殊都不知道怎么混过来写 C/C++的。

@microxiaoxiao 你这废话对谁都没什么用，正常情况到底谁是杂毛自己最清楚。
但是还得多吊一下你的阅读理解水平就挺杂毛的。
代表？我需要代表什么了？搁你这？你谁啊，配我去理解你这和别的地方有什么不同？
说到底，你什么时候产生你配浪费特定的谁的时间被收拾的错觉了？虽然观点行事颇为腌臜，你也没到人人得而诛之的斤两吧，所以被收拾也是随缘的事。就是愿意求仁得仁的，我还不愿意普渡众生呢，何况你这种没礼（脑）貌（子）读不懂空气的。

……然后最后一 bug 就是发现这项目多余的，整个砍了？