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

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

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

关于「发明人自己写初学者书」，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

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


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

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

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