gc 语言应该要显式 close，因为你无法控制 gc 什么时候调用析构函数，是巨大的 bug 隐患。

@wh469012917 你别笑。当年我很在乎性能，可是不知道 temporary table 就是不知道。我都用上 batch + null 判断来“想办法优化性能了”（大概确实能优化一点吧）

@wh469012917 所以你可以问问你的同事，有没有听说过临时表 TEMPORARY TABLE，知不知道 mysql temporary table ON HEAP 是内存表很快。

----

你看，如果不知道临时表这个功能，那你除了 for loop 还有啥办法？当年我不知道临时表的时候，我为了不那么愚蠢的 for loop，最开始我是给 id 切成一个 batch 一个 batch 然后 for loop 的。为了能用 prepared statement 我还强行填满最后一个 batch 然后靠 null 来区分是不是真的有数据。。。

@superhxl python 默认的不是两两比较排序，而是快速排序，只比 N log N 次。

所以你期待的 S1 < S3 + S3 < S2 imply S1 < S2 不存在。

你这个需求可以建图然后用拓扑排序。

@shijingshijing

> SpaceX 毕竟刚刚出大气层，还没遭受火星上各种宇宙射线，各种高能粒子轰炸，Elon Musk 本身把安全性看的也不高，成本和快速迭代占了较高的优先级
-----

事实上我觉得这才是快速进入太空时代必要的。NASA 这种慢吞吞的风格才是权宜之计。

@shijingshijing 我说的“太弱”也包含了“不能在太空稳定运行”这件事。

@CRVV Linux 内核不用 exception / iostream 是因为内核态上面的操作太奇妙，以至于不能用这些。可以理解。但是内核存在的意义就是让别的程序能够用 exception / iostream 这些高级玩意儿，更快开发程序不是么 233

至于 template 。那主要是 Linux 觉得 C++ 不利于这么大接近硬件的项目去兼容“傻逼程序员”。

其实软件工程从一开始就是试图用更高层的抽象去封装更复杂的显示细节。只有封装了才能让更“傻逼”的程序员更快的出活。内核就是干这事的，对于内核不能用 C++ 我觉得非常非常可以理解。要我说，用 C++ 也不过是权益之道，如果将来有一个高级抽象，可以有 C++ 的（执行时间）可靠性和 Java/C#（程序开发）可靠性，我举双手双脚赞成。
----

@shijingshijing @CRVV 所以我的论点倒不是说 C++ 多牛逼，大家一定要用 C++。而是觉得在 C++ 和 C 之间，C++ 提供的东西更多，理论上更容易出活。这个论调肯定没问题，不然游戏引擎为啥不用 C 写而用 C++ 写是不是？ C++ 开发速度 > 砍掉很多东西的 C++ > C 这是客观事实，不然 NASA 为什么不用裸 C 呢？

只是感叹这种抽象和硬件条件（包括物理学、发动机之类的制造水平）还不足以让星辰大海的征途一路通畅、高效快速前进罢了（叹息）

@wangxn 嘛，所以才需要这么搞。

如果真有一天没有多大试错成本，或者这种慢吞吞的推进速度实在太慢了，那肯定就不会这么写了。

@shijingshijing 就这么说吧。按照我的理解。为什么写航天器的代码这么局限？大概是因为上天的芯片太弱，给犯错边界太窄了（包括发动机也是），所以才容易出事。

为什么上天的芯片太弱？整体科技水平还不够强的芯片不出错。
----

这是这个时代的局限性，我觉得也挺对。但是我也盼望将来上个天和出门打个出租车一样简单，那个时候的写航天器代码一定不会是现在这样了。

@shijingshijing 那毕竟是 NASA，业务其实很集中。

我是觉得人类如果要征服星辰大海，这种龟速推进宇航器肯定是不行的。SpaceX 我估计不是这种写代码的风格，那种才可能快速市场迭代。。。所以你说 NASA 这种项目管理好不好？好也不好。。。

@agagega 这倒是，我也不爱用 iostream 。特别傻逼。

> 不太想。大言不惭地说，考研题目太低级，而且还要背政治，没精力，觉得不必要。

你为了好专业好学位付出一点代价怎么了。

@shijingshijing 那行吧，只能说这是用 human labor 堆出来的重量级工程。

但凡是地球上跑的软件项目就不走这条路了，因为这要花太多人力资源。

@bruce0 说起指令流水线和 data hazard 其实还可能会产生指令的乱序执行。比如老生常谈的

if (condition) {
with (lock) {
if (condition) { ...

这种 double-check-lock 在乱序执行面前会被虐成渣渣。解决方案是加入 memory fence 。

----

总之为啥 C++ 难，是因为太靠近硬件，需要掌握这些底层抽象才能用好。

@bruce0 哦对用机器码也不保险。

如果你用的是通用芯片，现代通用芯片在机器码的下面都有很多你“控制不了”的行为。比如英特尔的芯片微指令，一个机器指令其实是拆成若干指令，然后在芯片上有指令流水线（同一瞬间其实有多个指令的不同步骤正在执行）。这些指令“并行”会导致一些 data harzard 。当然，芯片帮我们处理好了。

但是因为是并行流水线所以会带来一些其他问题。比如遇到条件判断，现代芯片都会猜测这条语句的结果，然后提前进入某个分支执行。如果猜错了就“回滚”。对，分值预测就会导致你“执行时间不可控”。

还有比如 cacheline 、L1~L3 cache，atomic 指令，store buffer queue （在一个核上非 atomic 指令更新数据，另一个核不一定马上能看到）。这些都是你“不可控”的抽象。

----

现代计算机就是在一层一层你不可控的抽象上建立起来的。C++ 的各种语法和芯片上的这些复杂机制并没有本质差别。要理解、掌握这些抽象后面的原理，利用这些抽象才对嘛。

@bruce0 构造函数、深拷贝、浅拷贝，进化到 C++17 就是 move 语法等等。这些都是有规范的，一个能通过各种测试的编译器，用这些高级特性你都知道会发生什么。包括 -O3 。写出没有 Undefined Behaviour （遵守规范所以编译器也能给你完全能控制的代码）是 C++ 程序员重要的基本功啊。

@bruce0 可是，C++ 的 zero-abstraction 是有规范的啊。

在 template 方面根本就没有 UB 。如果你认为不是手写的就是 undeterministic，我觉得你应该用机器码才行啊。

@shijingshijing （正常写函数都不敢循环嵌套三层， 不然根本没法维护）

@tianming1992 可是，template 和动态内存毫无关系啊。。。倒不如说用了 template 让 C++ 省了很多需要动态内存申请的情况。不然怎么叫 zero-cost abstraction ？

另外 template poly 可以在不加虚函数表的情况下实现一定的继承多态之类的特性。

所以你到底会不会用 C++

@shijingshijing 神 tm template undeterministic 。