- 主题:用了一下std::visit，被人说太深奥了
这就是个话语权问题
不管在哪，都得听有权做决定的人的，其他人都是忍狠滚这三选一
【 在 toutouqi 的大作中提到: 】
: 开发产品不是置气，如果大部分工程师专业水平不行，看新语法也不行，那说明来到了不该来的地方，应该去更能发挥能力的地方高就。如果说这话的工程师专业水平不低，说明人家的精力没在新语法上，那就应该老老实实服从大多数，用通俗易懂的语法来写代码。
--
FROM 221.218.160.*
那些搞规范的人是语言专家，不是领域专家
比如图像处理库，他们并不是图像处理专家，而且图像处理领域可能发展很快，需求差异也很大，要抽象出一套通用的接口能应付各种图像处理需求，对他们来说是勉为其难。当然，可以委托领域专家和语言专家去合作搞这个，费这个劲等好几年后他们搞出来，还不如自己用opencv先上了。
std::filesystem搞出来，google不让用，说有安全隐患。
https://google.github.io/styleguide/cppguide.html#Other_Features
字符编码转换的codecvt搞出来，又废掉了，除了安全问题，还有难用的原因
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0618r0.html
语言方面，一是提高抽象/表达能力；二是提高性能上限。这两个都是基本的吧
【 在 lwp 的大作中提到: 】
: 语法不是一样搞不完
: 反正都搞不完，不如搞点大家都要用的东西
: 现在c++不是缺库，是缺标准库
: ...................
--
FROM 221.218.160.*
不是多难的事？站着说话不腰疼吧
网络的asio那个，一样有人喷它导致损失了20%的性能
【 在 lwp 的大作中提到: 】
: 我说了，有或没有你先撸一个出来，又不是多难的事
: 图像处理数据库的标准太多嫌麻烦，网络，加密，序列化，json这些非常基础的总得弄点吧，一个文件系统库还磨磨唧唧搞到17才有
: 一两家有想法不想用的自己去撸轮子就是了
: ...................
--
修改:z16166 FROM 221.218.160.*
FROM 221.218.160.*
换个角度来说这个，asio不在std里，就没法用了？
【 在 lwp 的大作中提到: 】
: 嫌慢的就去自己造轮子用啊
: asio对95%以上的场景性能都够用了，非要觉得自己场景多苛刻自己代码多高贵的那恕伺候不了
:
: ...................
--
FROM 221.218.160.*
这些推给vcpkg、brew之类的就行了吧
要c++委员会先折腾，然后每个编译器team的人也折腾、当保姆，也是强求
【 在 lwp 的大作中提到: 】
: 要编译三方库，系统部署，写cmake，配置ldpath，
: 搞不好还有版本匹配一堆破事
: 对新手太不友好了，本来就想收个tcp发个，udp
: ...................
--
FROM 221.218.160.*
那肯定啊，没有人说所有的问题都要在编译期解决，哈哈
【 在 ylh0315 的大作中提到: 】
: 那就根本搞不定 struct_to_json(JSON_OBJECT json,void* any
: _struct ,,,)；这类问题。
: 因为在编译这个函数时，根本不知道any_struct 是啥玩意儿，问题必须是在运行时解决。
: ...................
--
FROM 221.218.160.*