- 主题:boost库技术含量这么高的库，为什么工程中用的人很少？
正经搞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.*
抱歉打错了，确实，因为因为VSCode强制让IntelliCode用户迁移到Copilot，最近也正在喷VSC，打字的时候脑子过了一下这2个东西，结果给拼成错误的了。
不过关于VS，半年前我确实资格不够，但现在是用的多了。越用越知道VS是故意的，语言标准不好扭曲，那就在应用层面圈养你，这就是故意的。
然后作为一个闭源IDE，行为还不透明，在IDE中“add new items”结果文件路径不对，大哥你是IDE啊，C/Cpp的include""可是会收到文件在磁盘上物理位置的影响的啊，你这个IDE的“solution explorer”都已经显示在了“Source”下，结果你的逻辑分类跟文件在磁盘上的路径脱节？
你说的C++20支持问题，恐怕是因为正好赶上GCC从C语言到C++的迁移，所以说差距不大吧？如果按照对C++20的“完整支持”来算，cppreference的资料恰恰不能证明你的论点，而是会发现gcc支持的VS也支持，gcc部分支持的VS也是部分支持。而且如果看“完整”支持的话，要比较的是gcc11和vs2019 16.10了。但是不要看VS“2019”就算2019年，16.10版本的发布可是在2021年了，跟gcc11可是前后键不超过1个月。
当然，这是你非得提“完整支持”，所以比较的是功能最全情况下的最早版本了。
【 在 z16166 的大作中提到: 】
: 拜托先把名字打对再说。你要喷的不是“Visual Code”（话说这是个啥呢？），是VS对吧。VS的名字都打不对，说明你不常用它，基本也就没啥资格喷。
: MSVC对C++20的完整支持是最早实现的，gcc/clang现在都还没支持C++20的所有特性。你好歹上cppreference或者wikipedia查一下再喷啊
:
--
FROM 101.230.69.*
你说的这些，基于一个隐含的前提：逻辑视图和物理视图必须要割裂，割裂才是正常的。
可问题就在于，为啥非得把逻辑视图跟物理视图割裂开来呢？我通过文件夹组织结构，让
物理视图就按照逻辑视图来组织不就行了？也省去了.vcxproj这个中间商。
那好，退一万步讲，逻辑视图跟物理视图不是一回事，必须要由.vcxproj这个中间商垄断
配置解释权，那你VS也给做的好一点啊，通过配置，使得在已经有“source”文件夹、并
且“source”文件夹下的文件已经配置在了“Source”逻辑视图下这个情况下，让在逻辑
视图“Source”下新加的文件，就出现在“Source”文件夹下啊。
VS把本来就是不应该割裂的俩东西给分割开来，然后中间商又没做好很混乱，不该骂？
【 在 z16166 的大作中提到: 】
: vs的solution explorer那里的是filter，是逻辑视图，不是磁盘上的文件位置的物理
: 视图。
: logical view和physical storage的关系，打开*.vcxproj的xml文件看看就知道了。
: 也就是说同一个磁盘文件，可以添加到多个filter分组里，filter分组也不需要和磁盘
: 文件系统的结构一致。
: ...................
--
FROM 140.206.145.*
问题就是它也没提供啊。
中间层提供灵活性要有开放性和可配置性，否则就是挂着中间层的“灵活性”的羊头在卖
“圈养”“垄断”的狗肉，然后在功能上还不好使。
过这么久回复是因为web没法登录，一直以为是网站整个的问题，后来才发现term能登录
。
【 在 z16166 的大作中提到: 】
: 通过一层中间层来提供灵活性，这就跟虚拟内存地址空间、物理内存地址空间一样的道
: 理
: 不过这么久才回复，服了
--
修改:OrderPhoenix FROM 101.230.69.*
FROM 101.230.69.*
故意把物理视图跟逻辑视图认为的割裂，还能是“灵活”性？？？
更何况，同一个物理文件就不应该“加入”到不同的工程里面，而是应该通过“include
”机制。
至于filter分组，合着逻辑视图就只是纯逻辑是吧，连“配置逻辑视图中solution
explorer的Source分类与物理视图的Source文件夹相关联”这个设置都没有，还叫“灵活
”？
这么圈养用户，回头还是非跨平台的……
【 在 z16166 的大作中提到: 】
: 大哥，同一个物理文件能加入到不同的工程或者filter分组里，是“没提供灵活性”？
: 选择性无视啊，你这是。
: 不再回复这个问题，哈哈。
: ...................
--
FROM 101.230.69.*