- 主题:boost库技术含量这么高的库，为什么工程中用的人很少？
现在有包管理库就好弄了，以前在公司内裸机再加上自己裁剪的OS，搞起来那叫一个...
【 在 z16166 的大作中提到: 】
: boost就是std的试验田
: 不过现在有些打算进入std的库，不走boost这条路了，也就不在boost里。
: 编译一点也不麻烦吧，vcpkg或者bjam，除非要定制很细的bjam编译选项
: ...................
--
FROM 114.118.31.*
一个建议，对于业界普遍存在的诟病，最好不要老是质疑对方的水平。
如果对方是小白，那一款语言对小白很不友好，是不是也是设计失败的标志之一。
如果对方是驾驭过几千万行C++大工程的架构师，是不是更能说明问题。
总不能说，不喜欢boost的人，要么是小白，要么是老不死的守旧派吧。。。
归根结底，boost的定位就是“等待加入标准库”的备选，一个试验场而已，有人不喜欢太正常不过了。
【 在 z16166 的大作中提到: 】
: 这可能是误解吧，刻板印象，而且有这个偏见的人不少。
: 你可能只是把整个boost包下载了解压放在硬盘上，但是可以“用到什么，就只include什么”，不需要全部都include进去。
: 当然，这个库有基础的头文件，好多库都依赖这些基础的头文件，无法排除掉不要。这也正常
: ...................
--
FROM 114.246.238.*
小白或者业余玩家的诟病，那不是“业界普遍存在的诟病”
当然，也有一些职业码农也会觉得boost太大太臃肿，但我觉得这是偏见（人云亦云也好，不知道怎么选择boost feature也好），所以上面才打那么多字试图消除这种偏见，因为可以用vcpkg按需安装、按需include。
一门语言对小白不友好，是很正常的，因为语言有不同的level，越是low-level的，越需要掌握更细的知识才能玩转。C++就是high-level语言里比较low level的、靠近机器硬件的。
每种语言都有其用途和适用场合，如果不需要C++就能搞定的问题（比如用python等），即使自己没有C++基础也非要学习C++并用它搞定，那是费力不讨好。
"驾驭过几千万行C++大工程的架构师"并不一定就能说明boost臃肿、垃圾，只是说明boost可能不适合他的项目/产品，或者没进入他或者这个项目以往有话语权的那些人的喜好列表里。
Linus还喷C++垃圾呢，这比"驾驭过几千万行C++大工程的架构师"名气要大多了吧，但是这世界上就没人用C++了吗？
【 在 yuanmo 的大作中提到: 】
: 一个建议，对于业界普遍存在的诟病，最好不要老是质疑对方的水平。
: 如果对方是小白，那一款语言对小白很不友好，是不是也是设计失败的标志之一。
: 如果对方是驾驭过几千万行C++大工程的架构师，是不是更能说明问题。
: ...................
--
修改:z16166 FROM 221.220.174.*
FROM 221.220.174.*
boost这么香，用qt不好吗
boost的库跨度太大，覆盖太多专业领域
每个领域都有一大堆更专业更小的库
而且每个领域的作者都不一样，思路都不同
显然没有qt这种设计思路一致，有长期维护，代码优雅的好
大而全选qt
小而美选专业库
就没boost啥事了
【 在 aiworking 的大作中提到: 】
--
FROM 118.26.68.*
最新版的boost1.89消除了1300项依赖，目前体量已经小多了
【 在 speedboy2998 的大作中提到: 】
: 主要就是一个原因：太大。
: 一旦要用它，就要编译整个库。不如用很多其他高质量的 header onl 库，除非没有替代品。
: 比如我用 BOOST 最多的就是 asio， 也可独立于 BOOST 存在。
: ...................
--
FROM 36.163.208.*
你说的很对，但我不用boost。
在十几年前，c11还没有被当时的项目支持的时候，我确实不得不用boost，现在很抱歉，我看不到任何必要。c20/23的标准库已经足够强大了，如果我需要一些额外支持，我也倾向于寻找header-only的独立库。
哦对了，最后一点，我90%以上的工作是在mac/linux下，但即便win下，vs系列我也不觉得有多好，只是当年别家的更烂而已，而且与其说vs好，不如说va_x好。至于今天，可用的选项太多了，甚至win下我也不用vs编译器而是用clang+mingw
【 在 z16166 的大作中提到: 】
: 小白或者业余玩家的诟病，那不是“业界普遍存在的诟病”
: 当然，也有一些职业码农也会觉得boost太大太臃肿，但我觉得这是偏见（人云亦云也好，不知道怎么选择boost feature也好），所以上面才打那么多字试图消除这种偏见，因为可以用vcpkg按需安装、按需include。
: 一门语言对小白不友好，是很正常的，因为语言有不同的level，越是low-level的，越需要掌握更细的知识才能玩转。C++就是high-level语言里比较low level的、靠近机器硬件的。
: ...................
--
FROM 114.242.210.*
我不求谁用啥啊，爱用啥是个人喜好
说得好像我拿了boost或者vs的钱在给它做推广然后要求着谁用似的，哈哈
【 在 siyuetian 的大作中提到: 】
: 你说的很对，但我不用boost。
: 在十几年前，c11还没有被当时的项目支持的时候，我确实不得不用boost，现在很抱歉，我看不到任何必要。c20/23的标准库已经足够强大了，如果我需要一些额外支持，我也倾向于寻找header-only的独立库。
: 哦对了，最后一点，我90%以上的工作是在mac/linux下，但即便win下，vs系列我也不觉得有多好，只是当年别家的更烂而已，而且与其说vs好，不如说va_x好。至于今天，可用的选项太多了，甚至win下我也不用vs编译器而是用clang+mingw
--
修改:z16166 FROM 221.220.174.*
FROM 221.220.174.*
上面有人提到编译 boost 很麻烦，实际上目前 boost 已经不再需要单独编译了。
即使不是使用 vcpkg，也可以从 github/boost 的 release 中下载如 boost-1.89.0-cmake 带 cmake 的版本。
然后直接在你项目中 cmake 中用先通过 add_subdirectory(boost) 把 boost 目录添加进来，然后再用 target_link_libraries 添加用到的库，如：
target_link_libraries(your_project Boost::thread Boost::asio)
如此即可，不需要预先编译，也不必须使用 vcpkg，只要你的项目是 cmake 即可非常方便的添加 boost 依赖
--
FROM 39.172.225.*
说明有些人对boost或者其他的，经验和印象还停留在很多年前没更新
三个字：奥特曼
【 在 proc 的大作中提到: 】
: 上面有人提到编译 boost 很麻烦，实际上目前 boost 已经不再需要单独编译了。
: 即使不是使用 vcpkg，也可以从 github/boost 的 release 中下载如 boost-1.89.0-cmake 带 cmake 的版本。
: 然后直接在你项目中 cmake 中用先通过 add_subdirectory(boost) 把 boost 目录添加进来，然后再用 target_link_libraries 添加用到的库，如：
: ...................
--
修改:z16166 FROM 61.48.128.*
FROM 61.48.128.*
正经搞C++的才更应该排斥Visual Code。私货太多，故意设置陷阱降低代码的跨平台性。
其中最恶心的地方，在于C/C++标准库，作为一个平台无关的通用标准库，VS非得放在Windows SDK里面，想要include一个简单的stdio.h？对不起，整个Windos SDK安装一遍吧。这完全就是在圈养了。
至于说什么多此一举的stdafx.h头文件；在project里面增加一个“new item”，我鼠标右键命名是点击在了solution explorer的“Source Files”这个层级上面，增加之后的文件也是显示在了“Source Files”这个层级中，结果.cpp文件被放在了项目根目录下而不是“Source”文件夹下；modern C++新标准支持缓慢；我想指定语法高亮（我有几个.txt文件、.stil文件想要C++语法高亮）VS都不让，等等问题都是小事情了。
这是IDE啊，不是VS code、vim、emacs这种可配置编辑器，问题还要这么多，正经搞C++的才更应该排斥。
【 在 z16166 的大作中提到: 】
: 这可能是误解吧，刻板印象，而且有这个偏见的人不少。
: 你可能只是把整个boost包下载了解压放在硬盘上，但是可以“用到什么，就只include什么”，不需要全部都include进去。
: 当然，这个库有基础的头文件，好多库都依赖这些基础的头文件，无法排除掉不要。这也正常
: ...................
--
FROM 101.230.69.*