@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 / 阿里云 之类的各种云平台的虚拟机

我猜一猜，被动收入是指租金收入吧

既然收入足够、时间又多，那就做以前一直想干但没时间干的兴趣爱好

关于「发明人自己写初学者书」，Python 发明者还真的出过相关的教学书籍，而且不少哦：
https://www.amazon.com/Books-Guido-van-Rossum/s?rh=n%3A283155%2Cp_27%3AGuido%2Bvan%2BRossum

C 语言发明人也做过同样的事，出版的书一直到现在还能买得到。

我工作内容基本不靠 C++，只有少数例外。而我的个人项目主要是 C++，版本在 C++14 以上。
即使是那极少数会用到 C++的工作项目，也是尽量弄到起码 C++17 。

反正我是拒绝 C++98 的，当初就是嫌弃 C++98 而放弃过一段时间，直到 C++11 出现后才重学重用 C++。

OP 这需求，完全可以重新使用十几年前 eMule 流行的时期顺带流行过的 .par2 校验。

使用 par2cmdline 或者 MultiPar 给目标文件生成一堆校验文件，稍有损坏也不怕，只要损坏不多，就可以使用 .par2 文件恢复出原始内容

「到国内的一个 ip 后面就断了」

大概率就是 GFW 阻断的。

可以把 tacert / traceroute 的中间路径发上来，国内到国外、国外到国内，分别测一次。
发上来的时候记得删掉你们的业务 IP 那一行。

也可以用 BestTrace 、NextTrace 之类的软件来跟踪，它们会顺便给出 IP 地址的位置参考数据。

是不是国内与国外的连接？

如果是，那么很有可能是大墙发威（ /t/1115771 ）的“误伤”

@minami 全系 Intel 的话大概率能驱动起来

音箱的进步（不仅仅是“电脑”音箱的进步）其实就是声音物理学的进步。进步速度不算很快。

例如，最理想的“瞬态响应”应当是信号一来就立即响应，信号一停就立即停止。这就是所谓的“解析力”、“清晰度”。“瞬态响应”越差，播放出来的声音就越模糊。
这个“瞬态响应”不仅仅与喇叭有关、与箱体材料有关，也跟驱动电路紧密相关。单以电路元件为例，相关的设计改进被人研究得不少：
http://www.cntronics.com/special/381

对于喇叭设计、箱体设计、材料选择，这些东西的组合更需要花费大量时间去做声学计算、现场实测。


说个题外话，音箱、音质之所以有玄学，其中一个原因是，不同人对于声音有不同的主观喜好。
有些人就觉得“瞬态响应”中等的设备听起来更舒服，要不然声音会“干燥”；有人觉得“瞬态响应”就应该越迅速越好，要不然不够清楚。

主观喜好还包括音染喜好。
有些人喜欢低频猛（“动次打次”入脑），有些人喜欢中高频凸出（理由：人声清晰），有些人喜欢频响曲线一通均衡（比如我，偏好监听耳机/音箱）。

不同喜好的人扎堆聊耳机、音箱、音质，必定会导致当场变玄学。

@VchentozV 遇到管理员提权请求时，按 ALT+Y ，双手就不用离开键盘区域了

上下文都没有，需求也没提，大家没法判断 OP 该不该取消宽带

如果无法引入额外设备（例如新增机器专门监控），那就改一下习惯，前往图书馆之前把电脑“休眠”或“睡眠”，再拔掉电源

我日常工作主要靠 C# /.Net ，连网站也用 C# 那一套。对于需要节省脑细胞的场景，用 C# 真的很方便，在 IDE 内随便点几下鼠标就能找到满足需求的库，VS2022 甚至自带了简单的代码预测。而且现在 AI 辅助满天飞，问 AI 也能简单地获得可用的代码。

跟文章原作不同的是，我主要是在 Windows Server 运行 .Net 程序，用户鉴权使用 Windows 活动目录那一套。公司的内部限制导致只能用 .Net Framework ，难以安装 .Net 5+ 的版本（其实是公司服务器安装任何软件都不方便），然而即使是这样，大多数第三方库依然能够正常使用，基本足够解决工作需求。

内容实质上是推广，这也就算了，图片全部挂掉看都没法看

连推广都做得这么敷衍，会让人觉得信不过