- 主题:boost库技术含量这么高的库，为什么工程中用的人很少？
"工程中用的人很少"这个结论有支撑数据吗？还是只是感觉呢？
用不用，
一是看项目组中的人对此的掌握程度，
二是看喜好，特别是项目中有话语权的人的喜好，
三是看需求是否契合，既要了解boost，又要了解自己项目的需求
还有一点，某些boost库，已经改名为std::xxx，进入标准库了，所以你用的某些std:xxx，实际可能也是“用的boost”
--
修改:z16166 FROM 221.220.174.*
FROM 221.220.174.*
这可能是误解吧，刻板印象，而且有这个偏见的人不少。
你可能只是把整个boost包下载了解压放在硬盘上，但是可以“用到什么，就只include什么”，不需要全部都include进去。
当然，这个库有基础的头文件，好多库都依赖这些基础的头文件，无法排除掉不要。这也正常
因为就算你自己写一个项目，必然也有一些基础的building block，你项目里的其他东西会依赖这些底层的building block
还有个问题就是，有些人会认为boost包、VS2022这些尺寸太大，我认为嫌这些尺寸大的，基本上就只是玩玩C++的，不属于正经要学C++或者要靠C++吃饭的，因为正经要靠C++吃饭的人（搞信奥的学生不讨论，他们的电脑是父母出钱的），怎么会因为几百兆、几十G的磁盘空间就排斥工业界知名的IDE。
现在有vcpkg可以锁定boost的版本，不需要再把boost放到自己的产品的git repo里，也就不占用git server的空间。
【 在 yuanmo 的大作中提到: 】
: boost能提供的功能就是一堆调料，我只想要一盘醋，人家说不好意思我们不单卖，必须把辣椒酱豆瓣酱海鲜酱牛肉酱花生酱蒜泥香葱香油腊八蒜全打包了外加水果盘饮料和鸳鸯锅底都一起下单。我们是天下第一的调料库，你不买个全家桶你好意思说自己会吃饭吗。
:
--
修改:z16166 FROM 221.220.174.*
FROM 221.220.174.*
要编译整个库，也只是在vcpkg更新boost版本时做一次即可。
而且vcpkg可以只选择其中的一部分feature来安装、编译。
无论是CI服务器上，还是每个开发者的机器上，都可以做到这个。
其他时间，都只编译你的项目中include到的boost的一部分。
【 在 speedboy2998 的大作中提到: 】
: 主要就是一个原因：太大。
: 一旦要用它，就要编译整个库。不如用很多其他高质量的 header onl 库，除非没有替代品。
: 比如我用 BOOST 最多的就是 asio， 也可独立于 BOOST 存在。
: ...................
--
修改:z16166 FROM 221.220.174.*
FROM 221.220.174.*
boost就是std的试验田
不过现在有些打算进入std的库，不走boost这条路了，也就不在boost里。
编译一点也不麻烦吧，vcpkg或者bjam，除非要定制很细的bjam编译选项
【 在 kasshu 的大作中提到: 】
: 用的不少啊，就是编译麻烦，有些库因为好用都进入std了
--
FROM 221.220.174.*
小白或者业余玩家的诟病，那不是“业界普遍存在的诟病”
当然，也有一些职业码农也会觉得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或者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或者其他的，经验和印象还停留在很多年前没更新
三个字：奥特曼
【 在 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.*
拜托先把名字打对再说。你要喷的不是“Visual Code”（话说这是个啥呢？），是VS对吧。VS的名字都打不对，说明你不常用它，基本也就没啥资格喷。
MSVC对C++20的完整支持是最早实现的，gcc/clang现在都还没支持C++20的所有特性。你好歹上cppreference或者wikipedia查一下再喷啊
【 在 OrderPhoenix 的大作中提到: 】
: 正经搞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都不让，等等问题都是小事情了。
: ...................
--
FROM 61.48.128.*
这一阵我在看ESXi 9，我发现它的user world（也就是vmkernel之外的组件，用户态的组件）大量使用了boost。
--
FROM 61.48.128.*
vs的solution explorer那里的是filter，是逻辑视图，不是磁盘上的文件位置的物理视图。
logical view和physical storage的关系，打开*.vcxproj的xml文件看看就知道了。
也就是说同一个磁盘文件，可以添加到多个filter分组里，filter分组也不需要和磁盘文件系统的结构一致。
这个设计在初次使用时可能觉得反直觉、反人类，但是长期用之后就会觉得合理，因为多个工程/filter是可以共享同一个物理的cpp文件的。
C++20支持，一两年前我看到MSVC在release notes或者dev blog里宣称已经完全支持C++20时就去看过gcc/clang的现状，当时它们是落后的。
【 在 OrderPhoenix 的大作中提到: 】
: 抱歉打错了，确实，因为因为VSCode强制让IntelliCode用户迁移到Copilot，最近也正在喷VSC，打字的时候脑子过了一下这2个东西，结果给拼成错误的了。
: 不过关于VS，半年前我确实资格不够，但现在是用的多了。越用越知道VS是故意的，语言标准不好扭曲，那就在应用层面圈养你，这就是故意的。
: 然后作为一个闭源IDE，行为还不透明，在IDE中“add new items”结果文件路径不对，大哥你是IDE啊，C/Cpp的include""可是会收到文件在磁盘上物理位置的影响的啊，你这个IDE的“solution explorer”都已经显示在了“Source”下，结果你的逻辑分类跟文件在磁盘上的路径脱节？
: ...................
--
修改:z16166 FROM 222.129.207.*
FROM 222.129.207.*