- 主题:我就觉得c++现在纯粹就是标准库不行
赶快 fork 一个 qtcore，把 Q 前缀去掉就是最佳的 C++ 标准库。
【 在 libgcc (乞讨积分,求施舍,长期有效) 的大作中提到: 】
: 标准库一直残废几十年
: 直到c++20之前map连个contain都没有,string什么的就更别说了
: 而且模板库本身也比较难用,概念很多,报错处理也很怪,比如你想用printf打出fstream
: ...................
--
FROM 59.60.57.*
qtcore 差不多对应 stl + 部分 boost，我用 qtcore 写了好几个 linux 服务端程序了。单机日请求上亿次还可以。
【 在 here080 (hero080) 的大作中提到: 】
: 不行的，QT只适合桌面UI程序。很多场景不能这么用的。
--
FROM 110.81.41.*
没有。。够用就好。我写的是应用层的东东，反正两台机器不够就用四台机器。
【 在 here080 (hero080) 的大作中提到: 】
: 千QPS对于我写的东西来说有点小。
: 但是我觉得也应该可以看出差别了。
: 你有对系统使用资源量的监控吗？比如CPU和内存使用量。
: ...................
--
FROM 112.47.122.*
是的。目前我写的东东都是小规模流量的，大规模自然有大规模的写法。可以理解成我把 c++ 当作 go 来用。
如果需要大规模，需要另外的写法。
【 在 here080 (hero080) 的大作中提到: 】
: 我对QtCore的实现不熟。但是按你以往发文的情况来看滥用shared_ptr很普遍，加上各种中高开销的抽象方式。
: 我用的场景如果这么搞，估计多出来的机器钱能养好几个码农了。
--
FROM 112.47.122.*
stl 只有基础的容器和语言设施啊。写程序又只用这些东东。比如我写的程序提供 http 接口，需要解析个 url query，保存文件的时候还要考虑文件名里面有没有带 .. 导致覆盖系统文件，用 QtCore 这些事情全都帮我解决了。
上面牛奶海的帖子说得好，Qt 代表着开发效率，stl 代表着运行效率。
【 在 here080 (hero080) 的大作中提到: 】
: 其实现在C++新标准下标准库已经越来越容易用了，学习难度也降低了。
--
FROM 112.47.122.*
说到 shared_ptr<>，我发现使用协程以后, shared_ptr<> 减少了。
我猜是因为不使用协程的话，会出现大量回调函数，回调绑定变量时需要使用 shared_ptr<> 让变量跳出当前函数的生命周期。
而使用协程以后，不再有回调函数，函数之间都是简单直接的调用与被调用关系。原本 shared_ptr<> 的变量，可以被申请放在栈空间里面，传递时使用 & 或者直接传递值，shared_ptr<> 被大量消灭了。
所以大家可以期待一下 c++20 的协程支持。
【 在 here080 (hero080) 的大作中提到: 】
: 我对QtCore的实现不熟。但是按你以往发文的情况来看滥用shared_ptr很普遍，加上各种中高开销的抽象方式。
: 我用的场景如果这么搞，估计多出来的机器钱能养好几个码农了。
--
修改:hgoldfish FROM 112.47.122.*
FROM 112.47.122.*
差不多的意思。反正用了协程以后，用引用就行了。智能指针都可以省起来。unique_ptr<> 也不需要。
【 在 here080 (hero080) 的大作中提到: 】
: 回调应该使用unique_ptr
: shared_ptr只应该用在生命周期非常不确定的场景。但是这种场景本身应该严格限制。就算不考虑效率，毕竟shared_ptr不是真的GC，是不能处理循环引用的。
--
FROM 112.47.122.*
一个 QUrlQuery 类型而已，QtCore 里面直接搞定啊。。这个功能都要专门的库，早晚跟 js 一样，一个小工程依赖上千个模块。
还有处理 .. 文件路径也算是标准库的功能了。
【 在 here080 (hero080) 的大作中提到: 】
: 处理url当然要用专门的库了。这是两个问题。
--
修改:hgoldfish FROM 112.47.122.*
FROM 112.47.122.*