现在开发中的产品几十万行 C++ 代码
几乎就是模板类，模板函数组成的
很少看见 cpp，基本都是 hpp
开发了 7 年了，终于要 release 了
搞不懂那些人为啥当初选择了模板一条路走到死
【 在 nickwang 的大作中提到: 】
: 同意，对于我这种手脚慢的C++17都已经能满足大部分要求了，同感觉库是最大的短板，模板很难debug，日常真正需要模板的机会很少，debug浪费的时间远远不如带来的好处。
--
FROM 117.35.111.*

什么行业，容我拜一下。
【 在 litguy 的大作中提到: 】
: 现在开发中的产品几十万行 C++ 代码几乎就是模板类，模板函数组成的很少看见 cpp，基本 ...
--
FROM 113.137.163.*

qtcore 差不多对应 stl + 部分 boost，我用 qtcore 写了好几个 linux 服务端程序了。单机日请求上亿次还可以。

【 在 here080 (hero080) 的大作中提到: 】
: 不行的，QT只适合桌面UI程序。很多场景不能这么用的。
--
FROM 110.81.41.*

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.*

千QPS对于我写的东西来说有点小。
但是我觉得也应该可以看出差别了。
你有对系统使用资源量的监控吗？比如CPU和内存使用量。
还有你有试着对比把qt改成标准库，相同服务程序的资源使用量差别有多大吗？
【 在 hgoldfish 的大作中提到: 】
: qtcore 差不多对应 stl + 部分 boost，我用 qtcore 写了好几个 linux 服务端程序了。单机日请求上亿次还可以。
:
--
FROM 76.126.252.*