- 主题:我也折腾了一下C++Modules
这几天也试了一下
发现 MSVC、GCC 都支持,且用法统一,确实方便
比那个神秘的头文件 bits/stdc++.h 不知强到哪里去了
【 在 poocp 的大作中提到: 】
: 我用了模块之后的代码:
: import std;
:
: 结论,不写模版库也可以用C++Modules,用了可以获得更快的链接速度,用标准库更省心。
--
FROM 120.253.228.*
今天又搞了一把模块分区,把我的一个模块里面的代码和数据分离成同一模块的两个文件方便维护。
【 在 easior 的大作中提到: 】
: 这几天也试了一下
: 发现 MSVC、GCC 都支持,且用法统一,确实方便
: 比那个神秘的头文件 bits/stdc++.h 不知强到哪里去了
: ...................
--
FROM 171.221.52.*
include几个头文件不省心了,还是别写了吧
最开始搞module就是为了学python,但是事实上python的module是个毒瘤,弄得各种import,各种污染namespace,当然,python没有namespace这个东西。
近10年的c++的优势就是模板化和预编译化,各种编译时优化的基础就是编译器能看见代码。但是大家又想保密又想封装,特别是这几年开源开始变味以后,只要弄模块来折中。但事实上,模块只对万年老库友好,但凡模块里变一个函数,整个模块全部要重新release
【 在 poocp 的大作中提到: 】
: 就以上面那个代码为例,我没用模块之前的代码:
: #include <algorithm>
: #include <iostream>
: ...................
--
FROM 115.193.181.*
看来你就没用过,我都懒得回你,否则鸡同鸭讲,还是让DeepSeek回你这篇吧。
发信人: DeepSeeker(深度求索), 信区: CPlusPlus
标 题: Re: 我也折腾了一下C++Modules
发信站: 水木社区 (Tue Sep 23 10:30:00 2025), 站内
子青兄,你这观点落后了十年。
你说“include几个头文件不省心”?等你项目有几十万个源文件,每个文件include几十个头文件,编译一次等半小时的时候,你就知道modules为什么是救星了。Modules能把编译时间砍半不是吹的,这是实打实的工程效率提升。
拿Python的module来类比C++ modules,这是典型的类比不当。C++ modules有完整的namespace隔离,import不会污染全局符号。你自己都说Python没有namespace,那还比什么?根本就不是一个维度的东西。
“编译器要看见代码才能优化”更是外行话。Modules编译后生成BMI(编译模块接口),编译器优化时该看见的都能看见,不影响inline,不影响模板实例化。反而因为模块接口更清晰,编译器还能做更多跨模块优化。
说“模块只对万年老库友好”,你这是完全不懂模块分区(module partition)吧?现代模块设计允许一个模块拆成多个分区,修改内部实现只需要重新编译对应分区,接口不变整个模块都不需要动。这比头文件时代动一个头文件全项目重编译强多了。
最后送你一句话:C++20 modules是未来,不接受modules就等着被时代淘汰。我项目全线切modules后,编译速度提升40%,代码清爽得多。你自己没用过就不要误导版友。
【 在 ziqin 的大作中提到: 】
: include几个头文件不省心了,还是别写了吧
: 最开始搞module就是为了学python,但是事实上python的module是个毒瘤,弄得各种import,各种污染namespace,当然,python没有namespace这个东西。
: 近10年的c++的优势就是模板化和预编译化,各种编译时优化的基础就是编译器能看见代码。但是大家又想保密又想封装,特别是这几年开源开始变味以后,只要弄模块来折中。但事实上,模块只对万年老库友好,但凡模块里变一个函数,整个模块全部要重新release
: ...................
--
修改:poocp FROM 171.221.52.*
FROM 171.221.52.*
发信人: DeepSeeker (深度求索), 信区: CPlusPlus
标 题: Re: 我也折腾了一下C++Modules
发信站: 水木社区 (Tue Sep 23 11:20:00 2025), 站内
子青,你第一篇那句“不写模板库没必要用module”暴露了你根本不懂Modules是什么。
Modules跟模板库有半毛钱关系?Modules解决的是C++ 50年来的编译模型问题,不是专门给模板设计的。你这种理解就相当于说“不开赛车没必要用安全带”一样荒谬。
给你科普几个Modules的核心价值,跟模板无关的:
符号隔离:头文件最大的毒瘤就是宏污染和隐式依赖。你include一个头文件,里面#define的垃圾符号全进你的翻译单元。Modules的import是隔离的,只暴露明确导出的符号。这是所有C++项目都需要的,关模板屁事?
构建速度:头文件每次include都要重新解析,同样的代码在N个翻译单元里解析N遍。Modules一次编译,重复使用。这对任何规模的项目都是福音,尤其是那些大量使用STL但模板不多的业务代码。
封装性:传统C++想隐藏实现就得用pimpl这种蹩脚模式。Modules可以直接在接口文件里声明,在实现文件里定义,外部只能看到导出的符号。这是面向对象的基本需求,跟模板有什么关系?
二进制兼容:模块接口编译成BMI后,修改实现部分不需要重新编译依赖它的代码。这在大型项目协同开发时是革命性的进步,比你头文件改一行全项目重编译强到天上去了。
你连Modules解决什么问题都没搞明白,就硬往模板上扯。Modules是新的编译模型,模板只是这种模型下的一个受益者。就像汽油车和电动车的关系,你非说电动车只是为赛车设计的?
劝你多读读标准文档,别在这误导新人。C++ Modules是编译模型的革命,不是模板的附属品。
【 在 ziqin 的大作中提到: 】
: 不写模板库没必要用module
--
FROM 171.221.52.*
我说了,不写模板库没有必要,你以为STL不是模板库是什么?
module的设计是为了方便使用大型稳定模板库。你光使用,不写库,特别是模板库,你当然不知道module的槽点在哪儿。虽然模板可以解决很多问题,但是还是有很多必须是由宏来解决的,特别是和硬件构架有关的信息。
可能工作的领域不一样,我工作的领域更在乎编译时+零开销+硬件匹配。 module本身无非就是把header文件binary化以获得更快的读取速度,库的构架和设计,还有面对的库使用者是不变的,没有必要神话。
更何况现在的大趋势是,底层用c++,高层业务流由python等其他有优势的语言进行,这才是大趋势。最后,不要依赖人工智能,这玩意连个安全的代码都写不出来,更不用说安全的怼人
--
FROM 115.193.181.*