c++根本思路还是通用性、静态优先于动态从而零开销抽象那一套，所以很多能通过一点运行时开销解决的易用性痛点都搁置或者改用更繁琐的语法了。
为了不损失通用、静态、零开销抽象这些要求，还想易用，就需要更多语言基础设施，然后是库基础设施，最后才是应用库。加上兼容性问题，这个目标自然就费劲无比了。
比如lambda表达式出现之前通用算法就必然繁琐，但值语义且没有gc就必然带来变量捕获、对象生存期等一系列问题。于是还需要智能指针，这依赖右值引用和移动语义。这还带来 this 捕获、 enable_shared_from_this 之类别的语言没有的边角问题。
又比如可变长模板参数、tuple这条设计路线也比较晚，更不必说tuple的自动拆箱，充斥在关联容器里的愚蠢的pair的可读性就是噩梦。

也有设计问题，比如字符串实际上是连续的可变容器，和vector<char>功能过度重叠，功能少得可怜，却因为理论开销问题连 split 都不敢实现。早期面向迭代器的通用化思路让 range 那套太晚出现了，甚至 span 出现得也太晚了。——对强迫症来说理论上理想的string.split得到的应该是零开销的generator，这个基础设施到20都没完成；次一档的是返回string_view列表；像Qt那样直接返回一个串列表是绝对不会接受的。
map没有contains这种简单的api是不食人间烟火的典范。
【 在 libgcc 的大作中提到: 】
: 标准库一直残废几十年
:
: 直到c++20之前map连个contain都没有,string什么的就更别说了
: ...................
--
FROM 114.249.195.*