3 ms·

I actually think this attitude is the reason modules are so slowly adopted. The committee did exactly what you suggest and relegated the preprocessor to the dus

I actually think this attitude is the reason modules are so slowly adopted. The committee did exactly what you suggest and relegated the preprocessor to the dustbin and modules are seeing slow adoption. The truth is 98% of the preprocessor is fine - it's ifdefs for platforms and defines of constants and inline functions that are defined exactly once and never redefined. Because modules supports none of this, that means we can't modulize Windows.h. Or zlib. Or gtest. The committee should have remembered that one of the selling points of C++ is C compatibility, and figured out a way to get modules to work with 98% or the preprocessor and forbid only the nasty 2%.

cogman10 1y ago
> The committee did exactly what you suggest and relegated the preprocessor to the dustbin Importantly, no they did not. They put a boundary on the preprocessor containing preprocessing within the module definition and not the code importing the module. And that's where a lot of the loss and compatibility problems have come into play. That's why you can't, for example, share a module between builds. Because the ifdefs that built the module in the first place may have changed from one build to the next. It was good that the committee bound the preprocessor, but they simply didn't go far enough. C++ is making strides to adding the language features needed to dustbin modules. A lot of the work of consteval can replace a lot of what the preprocessor is doing. > Because modules supports none of this, that means we can't modulize Windows.h. Or zlib. Or gtest. And see, that's the issue. Modules do actually support all this. We can in fact modularize windows.h, zlib, or gtest. The issue is the `windows.module` still has to be rebuilt with every application that imports it because those `ifdefs` could evaluate differently depending on what env variables the build system sets before building. The module can't be just a simple AST built once. Maybe once for a project, but that's about it. And that's the rub. Change anything that causes the module to recompile and you spend exactly the same time you'd spend on precompiled headers.

cogman10 1y ago

> The committee did exactly what you suggest and relegated the preprocessor to the dustbin Importantly, no they did not. They put a boundary on the preprocessor containing preprocessing within the module definition and not the code importing the module. And that's where a lot of the loss and compatibility problems have come into play. That's why you can't, for example, share a module between builds. Because the ifdefs that built the module in the first place may have changed from one build to the next. It was good that the committee bound the preprocessor, but they simply didn't go far enough. C++ is making strides to adding the language features needed to dustbin modules. A lot of the work of consteval can replace a lot of what the preprocessor is doing. > Because modules supports none of this, that means we can't modulize Windows.h. Or zlib. Or gtest. And see, that's the issue. Modules do actually support all this. We can in fact modularize windows.h, zlib, or gtest. The issue is the `windows.module` still has to be rebuilt with every application that imports it because those `ifdefs` could evaluate differently depending on what env variables the build system sets before building. The module can't be just a simple AST built once. Maybe once for a project, but that's about it. And that's the rub. Change anything that causes the module to recompile and you spend exactly the same time you'd spend on precompiled headers.