> Modules promise to significantly change the structure of C++ codebases and possibly signal headers’ ultimate demise (but probably not in my lifetime). It also opens the door to potentially have a unified build system and package manager, similar to Rust’s Cargo package manager; though I imaging standardising a unified build system would be one bloody battle.
I wonder how many folks, like me, have stopped using C++ because it's too much effort to manage the build system and the overhead of headers adds too much to compile time?
An enormous draw for alternatives, like Rust, Zig, Nim et al is that they simply don't have these problems.
Zig doesn't have a package manager like rust does. They are competing "non-official" implementations that are not compatible with each other. Zig is in the same state as C++ right now with vcpkg, build 2, conan, etc...
But there is an effort[0] from the "core team" (meaning Andrew Kelley the author or Zig) to push for an "official solution".
Maybe, the same way Zig makes cross-compiling C/C++ easier we might see a Zig package manager making C/C++ packaging easier too.
> stopped using C++ because [...] and the overhead of headers adds too much to compile time?
> An enormous draw for alternatives, like Rust, Zig, Nim et al is that they simply don't have these problems.
I'm using Nim full time at the moment in a large project.
Like Rust, it certainly does have the compile time problem due to parsing lots of files! Every compile, Nim processes every source file in the program, including libraries, and this can take minutes.
Unlike C++ where each source file can be compiled in parallel, and after a small change most files usually don't need to be recompiled, Nim's scan of the whole program's source files is single-threaded, so it's the slowest part of the build. Nim compiles to C, and the C compilation and linking steps are relatively fast because the C compilations are run in parallel and cached.
At the office c++ fans are using modules to fight back against the vast simplifications go, rust come with wrt to builds, dependency management. Alas modules are a step forward for c++ ... But ...
* It'll be decades before our existing c++ code base is converted to modules meaning same cmake, dpkg, and all manner of nonsense ...
* clibs used by c++ are not impacted
* Modules are unlikely to help for os headers
I'm trying to move to go when I can and pure rust otherwise. After many years of c++ build hell on top of legion internal c++ code .. building has become a cosmic pain in the butt.
When playing with modules, I noticed a major caveat that makes me dislike them very much: the standard says that modules must form acyclic graphs. This means you still cannot get rid of forward declarations and you must put interfaces and implementations into different files for any realistically sized code base. So, in terms of effort, you still have to maintain the equivalemt of headers, just with a different name and less preprocessor macro interference.
Although, this is for people who make modules, not for module users.
As long as modules are written and compiled, they're both faster and easier to use and re-use than headers+libraries, although I'm curious to see if this covers both multithreaded libs and not, debug/release symbols, 32 or 64 bits and so on. So far all those options means there are 8 versions for each lib.
I've heard that now, libraries built with a version of MSVC are compatible with future version of MSVC, which means I don't need to build libraries each time I use a new version of MSVC.
It's not, it still the same bullshit where you need to predeclare everything that is written bellow in your file or elsewhere
C++20 modules from 60 years ago when people didn't know how to design modules
They haven't looked at how languages such as D/Rust/Zig/Swift are doing, instead they went blind and they built a "new" thing with the limitations of their old design
Unfortunately modules support in major build systems (e.g. cmake) is falling behind, and without it modules are somewhat useless for general c++ projects. I've only heard of build2 having some support for modules.
They're different codebases, so as far as I know, they'll have different implementations, sure.
But modules themselves are standardized, and so you should expect that after some time, you'll have stuff that works on all implementations. I don't believe that any of them are complete yet, which is why you see these differences currently.
(Caveats: I have followed the development of modules semi closely but am by no means an expert.)
[+] [-] dleslie|4 years ago|reply
I wonder how many folks, like me, have stopped using C++ because it's too much effort to manage the build system and the overhead of headers adds too much to compile time?
An enormous draw for alternatives, like Rust, Zig, Nim et al is that they simply don't have these problems.
[+] [-] tempest_|4 years ago|reply
No messing with autoconfs, and make files that spit out some random gcc error I have to debug.
To be fair however I am also not too interested in c++ and its 30 years of foot guns either so take it for what its worth.
[+] [-] skywal_l|4 years ago|reply
But there is an effort[0] from the "core team" (meaning Andrew Kelley the author or Zig) to push for an "official solution".
Maybe, the same way Zig makes cross-compiling C/C++ easier we might see a Zig package manager making C/C++ packaging easier too.
[0] https://github.com/ziglang/zig/issues/943
[+] [-] jlokier|4 years ago|reply
> An enormous draw for alternatives, like Rust, Zig, Nim et al is that they simply don't have these problems.
I'm using Nim full time at the moment in a large project.
Like Rust, it certainly does have the compile time problem due to parsing lots of files! Every compile, Nim processes every source file in the program, including libraries, and this can take minutes.
Unlike C++ where each source file can be compiled in parallel, and after a small change most files usually don't need to be recompiled, Nim's scan of the whole program's source files is single-threaded, so it's the slowest part of the build. Nim compiles to C, and the C compilation and linking steps are relatively fast because the C compilations are run in parallel and cached.
[+] [-] pjmlp|4 years ago|reply
It is just many anti-IDE folks never get to adopt them.
[+] [-] scrubs|4 years ago|reply
* It'll be decades before our existing c++ code base is converted to modules meaning same cmake, dpkg, and all manner of nonsense ...
* clibs used by c++ are not impacted
* Modules are unlikely to help for os headers
I'm trying to move to go when I can and pure rust otherwise. After many years of c++ build hell on top of legion internal c++ code .. building has become a cosmic pain in the butt.
[+] [-] jcelerier|4 years ago|reply
> I'm trying to move to go when I can and pure rust otherwise.
I don't understand in which universe replacing includes by imports takes more time than a full rewrite in a different language
[+] [-] pjmlp|4 years ago|reply
[+] [-] gmueckl|4 years ago|reply
When playing with modules, I noticed a major caveat that makes me dislike them very much: the standard says that modules must form acyclic graphs. This means you still cannot get rid of forward declarations and you must put interfaces and implementations into different files for any realistically sized code base. So, in terms of effort, you still have to maintain the equivalemt of headers, just with a different name and less preprocessor macro interference.
[+] [-] hoseja|4 years ago|reply
[+] [-] pjmlp|4 years ago|reply
[+] [-] dathinab|4 years ago|reply
But wow is that a multiple degrees more complex then in most other languages.
[+] [-] otabdeveloper4|4 years ago|reply
You're not gonna use Rust or Zig to write code for some obscure DSP CPU with a ridiculous architecture and no OS.
[+] [-] jokoon|4 years ago|reply
Although, this is for people who make modules, not for module users.
As long as modules are written and compiled, they're both faster and easier to use and re-use than headers+libraries, although I'm curious to see if this covers both multithreaded libs and not, debug/release symbols, 32 or 64 bits and so on. So far all those options means there are 8 versions for each lib.
I've heard that now, libraries built with a version of MSVC are compatible with future version of MSVC, which means I don't need to build libraries each time I use a new version of MSVC.
[+] [-] asddubs|4 years ago|reply
[+] [-] Shadonototro|4 years ago|reply
You still have to predeclare everything......... and you can't have circular dependency....
They learnt nothing, and they missed an opportunity to be relevant again
C++ is definitely dead, at least to me
This is so sad..
[+] [-] glouwbug|4 years ago|reply
[+] [-] bmurphy1976|4 years ago|reply
[+] [-] mhh__|4 years ago|reply
[+] [-] phibz|4 years ago|reply
[+] [-] copperx|4 years ago|reply
[+] [-] Shadonototro|4 years ago|reply
C++20 modules from 60 years ago when people didn't know how to design modules
They haven't looked at how languages such as D/Rust/Zig/Swift are doing, instead they went blind and they built a "new" thing with the limitations of their old design
What a shame
[+] [-] tdiff|4 years ago|reply
[+] [-] pjmlp|4 years ago|reply
https://devblogs.microsoft.com/cppblog/moving-a-project-to-c...
[+] [-] qweqwweqwe-90i|4 years ago|reply
[+] [-] steveklabnik|4 years ago|reply
But modules themselves are standardized, and so you should expect that after some time, you'll have stuff that works on all implementations. I don't believe that any of them are complete yet, which is why you see these differences currently.
(Caveats: I have followed the development of modules semi closely but am by no means an expert.)
[+] [-] bigcheesegs|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] baybal2|4 years ago|reply
There is no real chance to see it becoming a part of the C standard, because C is just that compact, and simple.
Yet, pkgconf will be a perfect base for pan-C package metadata standard outside of the standard.
[+] [-] jcelerier|4 years ago|reply
[+] [-] bregma|4 years ago|reply
[+] [-] pjmlp|4 years ago|reply
I guess someone is still using K&R C book as reference instead of ISO C18.
[+] [-] schaefer|4 years ago|reply
[+] [-] pkrumins|4 years ago|reply
[+] [-] DerekL|4 years ago|reply