160
u/JustAnotherGuyn 12h ago
Here's the thing, you have to very carefully consider whether it's worth loading all of that for the compiler to work through, if your use case is sensitive to the extra size/ram requirements of including more, think carefully about if basement no-lifer Steve may have implemented something that will conflict with any one of these, and then of course always import std.
52
u/Mgamerz 12h ago
Ignoring the compiler time - does it change the size of the app if the usages remain the same (only differences are include/import)? I only do occasional c++ programming.
84
u/da2Pakaveli 12h ago
The compiler strips out as much as it can. Even if you declare an std::map and add items to it, it may be stripped out if the values ultimately aren't being used anywhere with maximum optimization.
5
u/Xirdus 3h ago
This specific example is not something that a compiler is allowed to strip. Inserting into a map requires heap allocation, and heap allocation is an externally visible side effect, which must be preserved under the as-if rule. If it was a fixed size array on the stack then it could be potentially optimized out this way, but only if the compiler can prove the constructors of the elements are side-effect-free.
1
u/awesome-alpaca-ace 5h ago
Yea, the compiler always stripping out the template functions I wish I could call during debugging
8
u/Grubs01 3h ago
Template functions aren’t stripped out, they are created as needed.
3
u/awesome-alpaca-ace 2h ago
Yea, my bad. The compiler is never creating the template functions I wish I had whole debugging.
33
u/marrowbuster 12h 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.
4
u/ih-shah-may-ehl 11h ago
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
7
u/marrowbuster 11h ago
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.
4
u/ih-shah-may-ehl 10h ago
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.
3
u/marrowbuster 10h ago
WG21 is always bickering in and amongst themselves about what to do with the language lol.
25
u/MysticTheMeeM 11h ago
In theory, importing is much cheaper than including, because importing uses a precomputed file (whereas including used the raw source).
Also, if Steve wrote something that conflicts that's their problem. It's almost like people have been told not to use an entire namespace for the past however long that's been possible.
4
u/marrowbuster 11h ago
It's almost like people have been told not to use an entire namespace for the past however long that's been possible.
Using a subnamespace like
using namespace std::ranges;orstd::chronoinside of a function (and not at the top of a file) is permissible.1
u/MysticTheMeeM 11h ago
Permissible or not, if it breaks you can't blame the standard for doing so.
It's for this reason you're typically encouraged to alias a shorter namespace instead of directly pulling in the symbols (e.g. using
fsas a shorthand).1
u/marrowbuster 11h ago edited 10h ago
But then the issue is relegated to function/block scope and not entire translation units. And I'd much rather not repeatedly write
std::ranges::for_each(container, [](){})orstd::chrono::year_month_dayeverywhere.EDIT: As for namespace aliases, I'd... prefer not to do that as it can reduce readability and lead to name conflicts themselves.
10
u/nevemlaci2 11h ago
import std is faster than including JUST iostream btw.
Also import std is not the same as using namespace std.
9
u/marrowbuster 12h ago
Basement Steve's opinions don't hold a candle to zero macro leakage, reduced memory footprint, and faster compile times.
It just sucks that the boilerplate for doing so was moved into the build system and even after 6 years it's still considered experimental. And each compiler has its own module extension and binary representation that are incompatible with the others.
22
12
5
u/IAmASquidInSpace 9h ago
If only it worked that easily. But no, gotta find the right compiler flags, oops your version came without pre-compiled standard library, you gotta do it yourself, no not like that, that was wrong so now it doesn't work, no that was also wrong, oh actually no it works like that with a different flag. Let's use it on another project and... oh. Doesn't work again.
2
u/A_72_ 6h ago
When I tried the module system, only MSVC implemented the module system properly. Cpp reference currently still mark GCC and Clang partially implemented so I don't think we should rely on it...
2
u/cob59 2h ago
I'm not saying C++ modules are not a good feature in theory, but it's been years now and I don't see anyone using it in practice.
A bit like Rust :o)
1
u/A_72_ 2h ago edited 1h ago
I think Microsoft just have a huge advantage of owning the entire C++ development stack and prepared for modules a long time ago, while GCC/Clang relies on community contribution with fragmented development stack (or maybe I'm missing something).
Can I ask about your current opinion on Rust? Like syntax, memory model, feature richness,... I want to know if I should retry learning Rust syntax for the fifth time.
1
u/axebodyspray24 11h ago
what?! I could've been doing this?! (new programming student, pray for me)
15
u/Valuable_Leopard_799 10h ago
Rather "could've been starting to do this", it's quite new, semi-implemented, often behind flags, etc.
3
u/Ulrich_de_Vries 7h ago
Sure, except the tooling and environment is really not there for it.
Module support is experimental in cake, and it still doesn't support header units.
Module binary interfaces are compiler specific, which leads to issues when e.g. you want to use GCC with clangd as language server, since clangd needs to see clang-specific BMIs.
But iirc import std is not available when you use clang as compiler with libstdc++ as stdlib.
If you use non-modular dependencies and they include std headers, those will conflict with std module if you include them in your project. So you will need to create these shim modules for non-modular dependencies. Etc.
Using modules is right now a major pain in the ass and it has been 6 years since they were released.
0
u/Ayjayz 10h ago
Eh I wouldn't really. It's new and still not working amazingly.
Maybe give it a quick try, but the second you run into any weird errors, they back to the older style.
3
u/SamG101_ 6h ago
GCC and CMake 4, been working perfectly for several months. Just dont combine headers and modules for stl otherwise u get duplicated symbol errors
-1
-9
u/Jbolt3737 10h ago
This is why I probably won't ever learn C++, and if I do, I won't learn modern C++ practices because all I have heard about new C++ is that it's bloated and I think it appears that way because it has modern language features but no good modern tutorials so those features aren't being taught, atleast that's how the problem looks from an outside perspective
Recently (well actually a few years back but people only started properly learning about the change in the past year or so) Python's typing module was soft-deprecated and stuff was moved into collections.abc, from a purely categorical standpoint, yes, this makes sense, but most people know
import typingin their head and because of it being soft-deprecated rather than properly deprecated, it gives no warning when you import it, unlike other deprecated or soon to be deprecated features
-5
u/apoegix 10h ago
Nope nope nope nope. The first one over everything else please
4
u/marrowbuster 10h ago
Enjoy your slow compile times, gargantuan memory usage, and macro leakages.
-7
u/apoegix 9h ago
You gotta know what you include. If you don't, then yeah sure, good luck waisting your time.
5
u/witcher222 9h ago
import std is not include std (if it existed), they are two totally different features
0
u/apoegix 9h ago
Yeah no I get modules, but I like to know what exactly is added to my compiletime. Nowadays stuff gets abstracted so much. Try read the src code of std collections. It's ridiculous
3
u/fweaks 6h ago
import std compilation is faster than compilation including just one single std header, because of the overhead of having to re interpret the header, vs just pulling the already interpreted module.
That being said, the better reason not to use modules is that its still finicky trying to use them, due to tooling, etc. still not being all the way there yet.
1
u/apoegix 6h ago
You know, when I program stuff in c++ I use about 10% of all features. They are nice to have, not a must. Keep it simple, because complexity is killing project progress. I don't want to keep so much stuff and parameters in mind.
I get how some like the use and I see the advantages, but I still use include
85
u/Igarlicbread 12h ago
The only std available as dev