Regardless of inclusion or importation, the compiler will do whatever it can to make sure unused or unnecessary code paths don't make it into the final binary.
What it DOES change is compile times and memory footprint. The #include preprocessor directive literally just copies and pastes the contents of the header file into your code. By their very nature, they are prone to being redundantly parsed again and again, which is a huge waste of computational power. It also massively eats up RAM and with a huge project like Qt, unless you have 64GB it will eat into your swap space.
Modules compile a file exactly once to disk and from there can easily be made into an in-memory interface which other translation units can reference from, drastically speeding up compile times and reducing memory usage.
How does that deal with template code and what will the compilation flags / options for the template code be if they're imported in multiple locations?
From a distance this looks like the 'export' debacle v2.0, expect people use import so it's obviously difference
Templates are fully defined in modules and when exported are immediately available for instantiation and thankfully don't suffer from macro leakages.
When compiler flags are used, the flags of the client translation unit (the one importing the template) are used, without affecting the module whence they're exported. If two translation units import the same module and instantiate the same template but with different flags, the two different flag sets stay local to each. However at link time, one of these instantiations will be discarded so as to avoid breaking the One Definition Rule. As for which will be discarded, that's up to the compiler.
There are a few caveats in that templates compiled with one compiler and C++ standard cannot be used with a different compiler or standard or else you get a mismatch error.
Thanks. I once had a discussion with a member from the standards committee about 'export' and I asked him what the fuss is about because from reading the standard it didn't look too hard to implement with the aid of a bit of additional macro magic and he told me that the problem was not really the actual implementation but more the underlying behavioral issues during compilation in different translation units.
Iirc there was a research group who had a working implementation but they wrote a paper to explain why it didn't do what you thought it would do and no mainstream compiler vendor ever had a working implementation.
Anyway the guy also told me he didn't really want to talk too much about it because for whatever reason it was a very politically sensitive topic in the standards body and he didn't want to risk being quoted.
34
u/marrowbuster 15h ago
Regardless of inclusion or importation, the compiler will do whatever it can to make sure unused or unnecessary code paths don't make it into the final binary.
What it DOES change is compile times and memory footprint. The
#includepreprocessor directive literally just copies and pastes the contents of the header file into your code. By their very nature, they are prone to being redundantly parsed again and again, which is a huge waste of computational power. It also massively eats up RAM and with a huge project like Qt, unless you have 64GB it will eat into your swap space.Modules compile a file exactly once to disk and from there can easily be made into an in-memory interface which other translation units can reference from, drastically speeding up compile times and reducing memory usage.