随便它改，只要 Office OneNote 没砍就行

C++的协程都已经出了好几年了

我上星期才发了个帖子，用协程写 Demo 程序： /t/1117106

关于“运动”摸鱼，可以参考大疆公司员工自曝的操作：
https://www.sohu.com/a/869136798_161795
——上完瑜伽课回公司拿包，被 HR 赶走，大喊“不要加班”

换个角度，既然不想 996 ，那就软对抗

比如在星期六上班时直接睡大觉，睡够了再干活

平时干活就慢慢来，怎么放松怎么来，如果被人催的次数多了，那就问问各大 AI ，如何搪塞过去或者怼回去

星期六睡醒干活甚至可以再慢一些

不知道你有没有跑步、撸铁之类的运动习惯，如果有，那就试一下在晚上加班时段直接去运动，简单来说就是“运动+晚餐”，比如傍晚 6 点钟先去运动，接着再晚餐，然后才回去办公室“工作”（摸鱼），反正这么一通操作下来，离下班时间也差不多了

如果你们的晚餐时段是员工自行安排，那就更好，先用一个月时间给办公室的人一个印象：你的晚餐时间非常不固定、十分混乱。
第一个星期：18:30 、19:15 、18:35 、19:00 、18:30 、19:35
第二个星期：19:00 、19:30 、19:00 、18:45 、19:45 、19:35
第三个星期：18:00 、19:00 、19:30 、18:30 、18:45 、19:45
第四个星期：19:30 、18:30 、19:00 、18:15 、18:45 、19:45
等到大家都习惯了你晚餐时间“飘忽不定”，那就直接“运动+晚餐”占用公司时间干私事

如果想做其他事情，也可以先试试“留下飘忽不定”的印象，给自己一点灵活度

我记得安装完 Windows 11 ，跳出来的 OneDrive 会问是否开启备份

我是取消勾选、关闭备份的，因为知道 OneDrive 空间有限，肯定放不下

这样就可以继续用 OneDrive 的文件夹同步，并且不影响其他文件夹

@ugpu 写文件 4K 对齐？对于调用标准库 fopen 、std::iostream 而言，并没有这种事。标准库的文件读写并没有 4K 对齐这种选项。
大概是想说现代硬盘的 4K 对齐吧？那是操作系统和文件系统的事情。调用标准库文件读写 API 的时候，操作系统已经帮调用者处理好背后的对齐了，调用者并不需要考虑硬盘“4K”对齐这种事。如果分区没做 4K 对齐，开发者想要干预也没法干预。

看来需要打开 Visual Studio Installer ，点击“更多”，选“修复”

可以用 vscodium ，记得不要安装任何插件，要不然一样变慢

Ctrl+F 无法默认搜索？

请问 OP 是不是想讲 CTRL+SHIFT+F 这个搜索？

@aqtata 哈哈哈，这是 Eric Allman 风格，原版的 Allman Style 缩进就是 Tab

我长期用 C# ，习惯了 Allman 缩进方式
https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions#style-guidelines

C# 用空格缩进，到了 C++我就索性使用原版 Allman 缩进风格

@slideclick 网络 Proxy 类的工具（ 2022 年开始做的），需要在 Windows 使用，还需要照顾 BSD 系列，这种情况下 C++是最优解

尤其是 BSD ，全部自带 C/C++编译器，用 C++就不需要额外安装其他编译器工具链，哪怕为了在某些 BSD （例如 NetBSD ）使用 C++新版本引入了高版本编译器，也就改改编译参数的事

@nmap 我记得 2022 年，ASIO 开始支持协程。刚看了下 Github 和作者自己写的 Examples ，应该是在 2021 年 12 月的 1.22.0 开始支持的：
https://think-async.com/Asio/asio-1.22.0/doc/asio/examples.html
https://github.com/chriskohlhoff/asio/tree/asio-1-22-0

我现在才开始用算是有点晚，当然这也是为了等待编译器更新以及作者修 bug
ASIO 最新版（目前是 1.30.2 ）用起来还算顺畅

@billccn 或许，特殊机器可以特殊对待，比如以编译器 extension 的形式去处理。
假设“标准状况”下，char: 8-bit, short: 16-bit, int: 32-bit, long: 64-bit
那么开启 extension 就无视标准规定，按照机器的硬件手册内容去做。

如果硬件级别无法支持“假设的标准状况”，那就强制必须使用 extension 模式。

当然啦，这都是马后炮了，我有这种想法（强制开启 extension ）主要是因为知道 Linux 内核源码长期以来大量使用编译器扩展模式。微软编译自家系统时应该也是这样（ MSVC 也有自己的 extension ）。对于 20 世纪 80 年代的标准制定者而言，可能都预料不到编译器 extension 会用得满天飞。

@moudy 早期 C 语言可没有 typedef 这种做法，有人提到这么一句——
there is no "typedef" in early C
出处： https://news.ycombinator.com/item?id=13441621

@cnbatch 勘误一下，DP-7 的一个 Word （当时的最小操作单位）是 18 比特（不是字节）

补充一个：IBM 的“锅”也不小，DEC 之所以这么设计，可能是受到 IBM 的影响（毕竟要跟 IBM 竞争）。PDP-1 诞生前的 IBM 机器，字长就是 36-bit ，这里有发展史可以看：
https://en.wikipedia.org/wiki/Word_(computer_architecture)

1970 年之前的硬件操作数长度标准简直乱作一团

要甩锅那得甩给早期计算机的制造公司，尤其是 DEC

UNIX 是在 PDP-7 开发出来的，而 PDP-7 的一个 Word （当时的最小操作单位）是 18 字节：
https://gunkies.org/wiki/PDP-7

在 C 语言诞生的那个年代，既有 PDP-11 （ C 语言初版诞生的平台），使用现在大家熟知的 16bit / 32bit / 64bit 操作方式；也有 PDP-12 ，使用的是 12-bit ，以现在的标准来看够奇怪吧。

如果当时直接定死了各个基础类型的宽度，那么想要做源码级移植就麻烦多了。

就像如此简单的代码：

int number = 12;
printf("Number: %d\n", number);

int 是 18-bit 还是 12-bit ，又或者是 16-bit ，都由目标机器的编译器自己决定，在当时来看显然是很省事的。

发明人哪能预料到后来会统一为 8 / 16 /32 / 64 bit 标准呢

---------------

当然啦，ANSI / ISO 也有部份责任，第一个 ANSI C 标准制定的年代，已经是 8 / 16 /32 / 64 bit 标准的时期了，完全可以区分得更清晰一些，比如这样：

int 必须比 short 宽，long 必须比 int 宽

可惜标准只规定了最低限度，搞得后来不同系统的 int 和 long 都一塌糊涂。到了 C99 就只能用 macro 打补丁。

几乎都可以吧，比如 Google AI Studio 同样可以提前预设提示词

LM Studio 运行本地 LLM 也能提前预设提示词

我工作的公司，以前用 VMware ESXi ，现在迁移到云供应商，使用 AWS / GCP / Azure / 阿里云 之类的各种云平台的虚拟机