@exch4nge atomic_load 要自己维护引用计数。

不过你说得对，多线程写同一个 shared_ptr 并不安全。但是多线程读是安全的，因此我们可以这样：

std::shared_ptr<...> yourData;
std::mutex yourDataLock;


// 载入数据的函数
void loadData() {
// 载入
std::shared_ptr<...> newData;
// 更新
{
std::unique_lock<...> lockGuard(yourDataLock);
yourData = newData;
}
}

// 使用数据的函数
void useData() {
std::shared_ptr<...> theData = yourData;
// 使用 yourData
}

// 全局或者某个单例
std::shared_ptr<...> yourData;


// 载入数据的函数
void loadData() {
std::shared_ptr<...> newData;
// 载入
yourData = newData;
}

// 使用数据的函数
void useData() {
std::shared_ptr<...> theData = yourData;
// 使用 yourData
}

@fxxkgw 研发不要成本的嘛？
---

身为程序员享受高工资，却不愿意为了别人写的软件掏钱。

为什么会认为精通某些技术的人不能快速出活？

盲猜你的值其实是 0x251F11 ，打错了

盲猜你的值其实是 0x241F11

因为翻墙规则再复杂也是不完善的。与其家人遇到哪个视频站卡顿很慢，怀疑是不是翻墙规则不行或者翻墙挂了，还不如从来不让他们用翻墙。。。

@vcfghtyjc 那能不能编译前自动给每个 data structure 都加个判断，除非声明就是要重复引用？
----

编译器其实没那么弱鸡，C 语言的头文件 include 也挺快。C++ 之所以那么慢还是因为生命定义全部放进头文件了，而且全都是超级复杂的模板。meta-programming 你学习一下就知道多强大了，这玩意儿可是编译期就图灵完全的。

相当于你能在代码里写递归、写斐波那契数列、写 whatever 东西，让编译期在编译的时候把结果算出来，而不是在运行的时候算出来。当然，前提是你写得出来。

@vcfghtyjc 编译器不能 cache 一下每个文件的处理结果，遇到相同的文件直接用之前处理好的结果吗？
----

这就是 C++20 module ，但是前提是要承认“一个头文件里面的行为不受它之前 include 的其他头文件影响”。

现在的编译流程不具有这个约定。你八竿子搭不上边的 #define 可以影响到后面 include 的头文件。

@vcfghtyjc 你说对了，源码长度就是很长，而且还很复杂。

纯 C 语言的头文件一般只有声明所以速度相对快，但是 C++ 不同。为了追求 zero-cost abstraction ，C++ 的很多东西声明和定义全部都在头文件里面，而且模板 meta-programming 对于编译器是复杂的东西。这样叠加上去就，超级慢。一个 C++ 源代码文件 include 展开以后有几百上千 KB ，几百上千个 template class ，我觉得毫不意外。每个源文件都给你来这一套，想想多复杂。

C++20 的 module 就是规定，一些头文件不受其他头文件 macro 的影响。这样你就能预编译这些头文件，就不会有那么多重新编译的开销了。

在 C++20 module 前，业界最佳的实践是 Qt ，大量使用 private class + pointer ，尽量避免使用 template ，达到了很好的编译速度。然而，由于使用这两个技术，所以毕竟不是 zero-cost abstraction ，因此在运行速度上是打折了的。当然比起 node.js 还是秒杀。

最后简要介绍 zero-cost abstraction 。这东西看一个例子：

* C 语言的库函数 qsort 要传入一个函数指针。
* C++ 的库函数 std::sort 传入的是模板函数。

函数指针是不能内联优化的，因此每两个元素比较都不得不进行一次函数调用，有固有性能损失。
模板函数是可以内联优化的，相当于消除了这一次函数调用。更何况消除以后 C++ 可以进一步做指令集优化。

所以 C 语言 qsort 比 C++ 慢。

提个小建议：类型声明用 Arg 挺不友好。。。

建议考虑用 dataclass 包一层，或者参考 Pydantic 。尽量用内置变量 比如 int 和默认值推断你的界面

是的，而且老龄化劳动力减少必然会造成很严重的经济危机。根本不是什么人少了就不内卷了

linux mint

ES 的底层是 Lucence ，LUCENCE 在我当年学习的时候，分页原理应该是直接用关键词抽出来一些倒排索引，然后用优先队列对倒排索引进行合并，上面的结果打分以后用一个大小为 K * page_size 的堆保存最好的前 K 页结果然后返回第 K 页的内容。

顺便真有人上杠杆问券商融券（你就理解为借钱）买股票。。。。但是跌停卖不出去，强制平仓都平不了，眼睁睁看着它跌停，最后倒欠券商几千万。因为上了杠杆，所以几百万本金亏几千万是很容易的。

有一种东西，叫做流动性风险。
----

通俗一点，当资产一直在上涨的时候，傻子都知道持有，因此不愁卖不出去。此时给你一种错觉：资产变现很容易。

然而，当楼市开始下跌的时候，如果你不是那个率先抢跑的人…… 那你只能坐看手中的房产一天天贬值而无法变现。哪怕打七折都没法变现。。。这就是流动性风险。

房产说的远了，你不访问问为啥人家买股票追涨还是输得一塌糊涂。。。很简单，涨的时候刚买进去，连续给你来两个跌停。跌停哦，卖单一堆一堆压着，所有人都是跌停价想卖，等你挂单根本轮不到你卖。两个跌停是什么概念？主板 -19%，科创板 -36%

更何况有时候给你来五个跌停。。。 -68%。哭去吧

这就是流动性风险

@davidshao LaTeX 巨难伺候。

Texpad (mac) 自己做了个实时渲染引擎，能支持一部分英文的 LaTeX 写作。

Overleaf 的速度还行，刷新一次渲染几秒钟差不多。可以自己部署一个放在 Linux Server 上。

其他的都不行。