我一直都说了，标准库这路子走歪了

还活在100M内存500MCPU的三十年前

天天想着给程序省几个指令几个字节，码农有至少3成精力都在面向编译器编程

问题是那个时候没啥网络程序，都是单机，确实能省一点是一点

现在这年代，上了网络之后响应都是上百ms级，http报文全都是txt文本，那压缩率不堪
入目也发了几十年了，除了nginx和mysql之类的还需要追求极致的性能和资源开销，其
它的谁在乎你是不是0开销啊

何况退一步说，就算要追求性能，遵循28原则一个程序最需要优化的点就那么10%-20%，
其它的地方慢不慢的快不快的根本无所谓，真正那10%和20%，也不是你少执行几条指令
就能优化得出来的，要么需要极致的算法要么需要异构计算要么需要操作系统的高级货
支持，光一个语言真的别太把自己想的太重要

c++坚持走性能这条路只能越走越窄，最后沦为开发浏览器数据库和各种语言的解释器和
虚拟机去了

c++现在最大的优势根本就不是性能牛逼，是能文能武能上能下，从底层指令和内存字节
到上层ui图像全都无缝兼容，标准库得赶紧做大不是做强，先把该有的全包进去，接口
能搞多点搞多点，能友好点友好点，要不然真是彻底熄了


【 在 here080 (hero080) 的大作中提到: 】
: 至少vector做到了0开销抽象，跟C数组一个效率。
--
修改:libgcc FROM 171.83.8.*
FROM 171.83.8.*

有 array 啊。
【 在 toutouqi (toutouqi) 的大作中提到: 】
: 见过一些人用vector替换指针，不reserve直接在循环里push_back赋值。感觉vector功能太多，应该另造一个array替代指针数组。
--
FROM 114.249.195.*

能上能下有什么意义？还不是因为不损耗效率。
哪门语言想做不能做到能上能下？
【 在 libgcc 的大作中提到: 】
: 我一直都说了，标准库这路子走歪了
: 还活在100M内存500MCPU的三十年前
: 天天想着给程序省几个指令几个字节，码农有至少3成精力都在面向编译器编程
: ...................
--
FROM 76.126.252.*

这个习惯不好。如果是可以有多个相同key存在的容器，这样就得一直查完，不能提前跳出。
有contain直接用比这种hack强
【 在 lambdai 的大作中提到: 】
: 是的所以只是判断contain时候就用count(key)
: :
: - 来自「最水木 for iPhone12,8」
--
FROM 76.126.252.*

重来的话我估计可能会放宽 map 的约束允许 B 树的实现，这种影响时空开销的设计决策可能比 contains 这样的小 API 重要得多。不过也不好说，因为这意味着增删元素会造成迭代器失效，也需要权衡。

Rust 就是这样选择的，abseil 也有一套基于 B 树的关联容器。

【 在 lambdai (lambdai) 的大作中提到: 】
: 肯定的
: 不过multimap实在是太罕见了。我好像只在production上用过一次
: 不知道从头开始演化的话，是不是contains会优先级高于multimap
: ...................
--
FROM 114.249.195.*