> 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.
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.