我就觉得c++现在纯粹就是标准库不行

libgcc
乞讨积分,求施舍,长期有效 03月25日 字数 915

标准库一直残废几十年

直到c++20之前map连个contain都没有,string什么的就更别说了

而且模板库本身也比较难用,概念很多,报错处理也很怪,比如你想用printf打出fstream

.tellg()的返回值,你甚至都不知道用%什么是最规范的

其它的我倒觉得还好,除了枚举没有字符串(像magic_enum)这样的实现,c++17以内,语法

层面基本上已经可以用的很自在了

内存什么的,有了unique_ptr,vector之类的,加上RAII,哪有那么多泄露不泄露的,少用裸

指针就是了.我一直不明白为什么还是有这么多人讨论c++的内存泄漏问题,我觉得这已经

不是modern c++的一个显著硬伤了

编译和包管理混乱也是一方面,但这个东西大多都是一次性的,配好了就完事了,也不会有

持续的影响,没有什么洁癖的直接上QtCore可以覆盖7成以上的基本功能了

头文件用习惯了也还凑和了

反正用了这十几年c++,我就是对标准库的残废很不满,非常不满,其它的倒多少都习惯了

而且C++在底层无缝链接设备和系统,自由操作内存,轻松对接simd/cuda等高级货,这些强

大的功能确实也是除c之外的其它语言很难赶得上的.有时候我在想,我的工作要换成其它

语言,还真是不会比用c++轻松多少

101 个回复
ziqin
子青|会挽雕弓如满月|西北望|射天狼 03月25日

contain和find有什么区别?

【 在 libgcc 的大作中提到: 】

: 标准库一直残废几十年

: 直到c++20之前map连个contain都没有,string什么的就更别说了

: 而且模板库本身也比较难用,概念很多,报错处理也很怪,比如你想用printf打出fstream

: ...................

hgoldfish
老鱼 03月25日

赶快 fork 一个 qtcore,把 Q 前缀去掉就是最佳的 C++ 标准库。

【 在 libgcc (乞讨积分,求施舍,长期有效) 的大作中提到: 】

: 标准库一直残废几十年

: 直到c++20之前map连个contain都没有,string什么的就更别说了

: 而且模板库本身也比较难用,概念很多,报错处理也很怪,比如你想用printf打出fstream

: ...................

libgcc
乞讨积分,求施舍,长期有效 03月25日

标准委员会那帮大爷们看不上吧

【 在 hgoldfish (老鱼) 的大作中提到: 】

: 标  题: Re: 我就觉得c++现在纯粹就是标准库不行

: 发信站: 水木社区 (Thu Mar 25 22:39:47 2021), 站内

: 赶快 fork 一个 qtcore,把 Q 前缀去掉就是最佳的 C++ 标准库。

: 【 在 libgcc (乞讨积分,求施舍,长期有效) 的大作中提到: 】

: : 标准库一直残废几十年

: : 直到c++20之前map连个contain都没有,string什么的就更别说了

: : 而且模板库本身也比较难用,概念很多,报错处理也很怪,比如你想用printf打出fstream

: : ...................

: --

: 灭绝人性啊

puke
人在江湖飘 03月26日

STL设计的就跟狗屎一样,还带歪了后面几十年的路线。

现在的C++就是一个缝合怪。

【 在 libgcc 的大作中提到: 】

: 标准库一直残废几十年

: 直到c++20之前map连个contain都没有,string什么的就更别说了

: 而且模板库本身也比较难用,概念很多,报错处理也很怪,比如你想用printf打出fstream

: ...................

toutouqi
toutouqi 03月26日

确实,模板库报错有时候看不懂,另外好多返回类型其实就是int或者size_t,但各种名字,这种挺烦的。

【 在 libgcc 的大作中提到: 】

: 标准库一直残废几十年

: 直到c++20之前map连个contain都没有,string什么的就更别说了

: 而且模板库本身也比较难用,概念很多,报错处理也很怪,比如你想用printf打出fstream

: ...................

nickwang
做更好的自己 03月26日

同意,对于我这种手脚慢的C++17都已经能满足大部分要求了,同感觉库是最大的短板,模板很难debug,日常真正需要模板的机会很少,debug浪费的时间远远不如带来的好处。

here080
hero080 03月26日

find完了还要再比一次啊,有时不好写。

if (a_very_long_variable_name.GetAVeryLongMethodName().find(key) == ???) // 我靠这里怎么写?

【 在 ziqin 的大作中提到: 】

: contain和find有什么区别?

here080
hero080 03月26日

不行的,QT只适合桌面UI程序。很多场景不能这么用的。

【 在 hgoldfish 的大作中提到: 】

: 赶快 fork 一个 qtcore,把 Q 前缀去掉就是最佳的 C++ 标准库。

lambdai
lambdai 03月26日

哈哈哈

我会用个auto&& obj 获得find()的receiver…

【 在 here080 的大作中提到: 】

: find完了还要再比一次啊,有时不好写。

: if (a_very_long_variable_name.GetAVeryLongMethodName().find(key) == ???) // 我靠这里怎么写?

: 【 在 ziqin 的大作中提到: 】

: ....................

litguy
随风而行 03月26日

现在开发中的产品几十万行 C++ 代码

几乎就是模板类,模板函数组成的

很少看见 cpp,基本都是 hpp

开发了 7 年了,终于要 release 了

搞不懂那些人为啥当初选择了模板一条路走到死

【 在 nickwang 的大作中提到: 】

: 同意,对于我这种手脚慢的C++17都已经能满足大部分要求了,同感觉库是最大的短板,模板很难debug,日常真正需要模板的机会很少,debug浪费的时间远远不如带来的好处。

here080
hero080 03月26日

你这就多了一个变量名。命名是很头疼的。

而且有些复杂表达式场景下这样并不一定安全。

另外你这算是典型的滥用右值引用了。

【 在 lambdai 的大作中提到: 】

: 哈哈哈

: 我会用个auto&& obj 获得find()的receiver…

: ...................

DoorWay
DoorWay 03月26日

什么行业,容我拜一下。

【 在 litguy 的大作中提到: 】

: 现在开发中的产品几十万行 C++ 代码几乎就是模板类,模板函数组成的很少看见 cpp,基本 ...

hgoldfish
老鱼 03月26日

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

【 在 here080 (hero080) 的大作中提到: 】

: 不行的,QT只适合桌面UI程序。很多场景不能这么用的。

DoorWay
DoorWay 03月26日

肯定看不上。开发者也有看不上的

API Design Part 1: Impact on the Performance (Qt vs STL example)

https://cukic.co/2014/10/03/api-design-and-impact-on-the-performance-qt-vs-stl-example/

【 在 libgcc 的大作中提到: 】

: 标准委员会那帮大爷们看不上吧 ...

litguy
随风而行 03月26日

苦逼底层码农,分布式存储

看着那些模板的轮子

搞不懂为啥那些人那么喜欢造轮子

【 在 DoorWay 的大作中提到: 】

: 什么行业,容我拜一下。

milksea
肥了,又肥了 >>>_<<< 03月26日

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什么的就更别说了

: ...................

milksea
肥了,又肥了 >>>_<<< 03月27日

如果找不到返回nullptr其实还能忍,返回 verylongname.anothername.end() 你也能忍?

【 在 lambdai 的大作中提到: 】

: 哈哈哈

: 我会用个auto&& obj 获得find()的receiver…

: ...................

here080
hero080 03月27日

千QPS对于我写的东西来说有点小。

但是我觉得也应该可以看出差别了。

你有对系统使用资源量的监控吗?比如CPU和内存使用量。

还有你有试着对比把qt改成标准库,相同服务程序的资源使用量差别有多大吗?

【 在 hgoldfish 的大作中提到: 】

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

littleSram
littleSram 03月27日

没有包管理,导致好的包无法便捷的分享

【 在 libgcc 的大作中提到: 】

: 标准库一直残废几十年

: 直到c++20之前map连个contain都没有,string什么的就更别说了

: 而且模板库本身也比较难用,概念很多,报错处理也很怪,比如你想用printf打出fstream

: ...................