- 主题:我就觉得c++现在纯粹就是标准库不行
find完了还要再比一次啊，有时不好写。
if (a_very_long_variable_name.GetAVeryLongMethodName().find(key) == ???) // 我靠这里怎么写？
【 在 ziqin 的大作中提到: 】
: contain和find有什么区别？
:
--
FROM 76.126.252.*
不行的，QT只适合桌面UI程序。很多场景不能这么用的。
【 在 hgoldfish 的大作中提到: 】
: 赶快 fork 一个 qtcore，把 Q 前缀去掉就是最佳的 C++ 标准库。
:
--
FROM 76.126.252.*
你这就多了一个变量名。命名是很头疼的。
而且有些复杂表达式场景下这样并不一定安全。
另外你这算是典型的滥用右值引用了。
【 在 lambdai 的大作中提到: 】
: 哈哈哈
: 我会用个auto&& obj 获得find()的receiver…
:
: ...................
--
FROM 76.126.252.*
千QPS对于我写的东西来说有点小。
但是我觉得也应该可以看出差别了。
你有对系统使用资源量的监控吗？比如CPU和内存使用量。
还有你有试着对比把qt改成标准库，相同服务程序的资源使用量差别有多大吗？
【 在 hgoldfish 的大作中提到: 】
: qtcore 差不多对应 stl + 部分 boost，我用 qtcore 写了好几个 linux 服务端程序了。单机日请求上亿次还可以。
:
--
FROM 76.126.252.*
我对QtCore的实现不熟。但是按你以往发文的情况来看滥用shared_ptr很普遍，加上各种中高开销的抽象方式。
我用的场景如果这么搞，估计多出来的机器钱能养好几个码农了。
【 在 hgoldfish 的大作中提到: 】
: 没有。。够用就好。我写的是应用层的东东，反正两台机器不够就用四台机器。
:
--
FROM 76.126.252.*
其实现在C++新标准下标准库已经越来越容易用了，学习难度也降低了。
【 在 hgoldfish 的大作中提到: 】
: 是的。目前我写的东东都是小规模流量的，大规模自然有大规模的写法。可以理解成我把 c++ 当作 go 来用。
: 如果需要大规模，需要另外的写法。
:
--
FROM 76.126.252.*
处理url当然要用专门的库了。这是两个问题。
【 在 hgoldfish 的大作中提到: 】
: stl 只有基础的容器和语言设施啊。写程序又只用这些东东。比如我写的程序提供 http 接口，需要解析个 url query，保存文件的时候还要考虑文件名里面有没有带 .. 导致覆盖系统文件，用 QtCore 这些事情全都帮我解决了。
: 上面牛奶海的帖子说得好，Qt 代表着开发效率，stl 代表着运行效率。
:
--
FROM 76.126.252.*
回调应该使用unique_ptr
shared_ptr只应该用在生命周期非常不确定的场景。但是这种场景本身应该严格限制。就算不考虑效率，毕竟shared_ptr不是真的GC，是不能处理循环引用的。
【 在 hgoldfish 的大作中提到: 】
: 说到 shared_ptr<>，我发现使用协程以后, shared_ptr<> 减少了。
: 我猜是因为不使用协程的话，会出现大量回调函数，回调绑定变量时需要使用 shared_ptr<> 让变量跳出当前函数的生命周期。
: 而使用协程以后，不再有回调函数，函数之间都是简单直接的调用与被调用关系。原本 shared_ptr<> 的变量，可以被申请放在栈空间里面，传递时使用 & 或者直接传递值，shared_ptr<> 被大量消灭了。
: ...................
--
FROM 76.126.252.*
这个没办法的。历史原因注定了。
依赖很多模块不是问题。
【 在 hgoldfish 的大作中提到: 】
: 一个 QUrlQuery 类型而已，QtCore 里面直接搞定啊。。这个功能都要专门的库，早晚跟 js 一样，一个小工程依赖上千个模块。
: 还有处理 .. 文件路径也算是标准库的功能了。
:
--
FROM 76.126.252.*
至少vector做到了0开销抽象，跟C数组一个效率。
【 在 xieyf 的大作中提到: 】
: stl追求极致运行效率？它跟效率不搭边好不好。
:
--
FROM 76.126.252.*