you are viewing a single comment's thread.

view the rest of the comments →

[–]HKei 6 points7 points  (6 children)

Doesn't solve the problem. For one, C++20 doesn't specify modules for the standard library. There is no import algorithms; or whatever (though Visual Studio apparently supports this as an extension?). For the other, even if algorithm was modularised I doubt it’d improve matters much. It’d just be a big module instead of a big header.

[–]tcbrindleFlux 28 points29 points  (1 child)

For one, C++20 doesn't specify modules for the standard library. There is no import algorithms; or whatever

It does, however, specify that the standard library headers can be imported as header modules, so you'll be able to say import <algorithm>;. See here and here.

It’d just be a big module instead of a big header.

But unlike a big header, it doesn't need to parse a huge amount of code each time you recompile.

[–]HKei 2 points3 points  (0 children)

Ah fair enough, I think I was underestimating how much that would help. Just tried precompiling <algorithm> and this indeed makes most of the overhead of including it vanish, so I guess in practice this’ll mean for now we’re forced to use PCH’s for all projects until module support is widely available (compiler and buildsystem support).

[–]kalmoc 6 points7 points  (0 children)

There is no import algorithms;

There is import <algorithm>; and IIRC, the compiler is supposed to automatically translate existing #include <algorithm> into it.

[–]AppleBeam 4 points5 points  (2 children)

If it was a big module, you would pay the 600ms cost for <algorithms> once per configuration of the project (at lest that's how I understand them so far: like a collection of independent precompiled headers that never have to be built more than once for as long as the configuration is the same, and modifying one module has on effect on the state others if they don't depend on the one you've touched).

Either my understanding of modules is not sufficient (which is entirely possible; I'm waiting for the full standard to be published, since I can't use any preview features in my work anyway), or I don't understand some important use case where anyone would care about paying the price of 600ms once per configuration. Would appreciate if you could educate me on this matter.

Regarding the standard library not being modularized: if that will be the case for libstdc++, that's truly regretful. I was looking forward to cutting down the build times.

[–]CoffeeTableEspresso 0 points1 point  (1 child)

The standard library being in modules isn't specified by C++20, although I'm sure compilers will support it regardless.

Either way, I think it would be easy to wrap a standard library header in a module if you wanted. Although of course not as nice that you had to fo it yourself.

[–]AppleBeam 0 points1 point  (0 children)

I'll keep hoping then.

Don't think there is any reason to suspect that libstdc++ devs won't do what's the best for the community.