Wait, does the C++ module proposal allow modules names to be different from their filenames? This sounds so strange, I've never used such a module system in other languages. I've always assumed C++ modules would somehow restrict the excessive liberty it has had from its headers and preprocessors. How did they arrive at such a weird idea?
I think this post has a clearly missing solution that is (essentially) a first stage in a build system.<p>Yes, C++ can be slow to build. But it's slow to build <i>because</i> of the includes and the code generation (and we still have to do code generation).<p>How much time does the author think it takes to pipe code through the preprocessor (for defines, not includes since in this case there are no includes), and tokenize?<p>I just checked the dependency files of a fairly large project (GNU Radio), and each cc file transitively depends on 414 files on average. In total in order to compile its 1339 cc files the compiler needs to open and read over half a million files.<p>So just in terms of data to read on this first pass it's faster by a factor over 400x. Add to that that you don't have to do anything in this pass except look for module dependencies, I bet it's several thousand times faster than a compile.<p>So in other words, if it takes you an hour to build your big project, are you saying you don't have one single second left over to calculate the dependency tree as a first pass?<p>And you only have to do it once (and then re-do files as source timestamps change).
I was just tonight watching Bjarne’s cppcon 21 talk[1] and he does not seem to think they’re dead.<p>OTOH, from what I can tell my compiler of choice, clang, has not improved its support since last time I dabbled with it unsuccessfully. But I could be Doing It Wrong. There seems to be very little stuff on the internet about actually using them which is not a great sign.<p>[1] <a href="https://youtu.be/15QF2q66NhU" rel="nofollow">https://youtu.be/15QF2q66NhU</a>
I can't help but notice that of all the names in the linked docs, there doesn't seem to be any from the companies that implement the actual C++ compilers. What's the stance of Clang/gcc/MVSC/... developers on this?
There's a 2016 CppCon talk here about making C++ Modules work at scale for Google's 100Mloc mono repo: <a href="https://www.youtube.com/watch?v=dHFNpBfemDI" rel="nofollow">https://www.youtube.com/watch?v=dHFNpBfemDI</a><p>So, apparently it can work. I don't don't how much Google's internal Module incarnation differs (if at all) from what was ultimately published in the standard, but I'd expect it to be similar.<p>The article discusses a problem of resolving dependencies between compiling different c++ files. I'm no expert, but I think this dependency graph is implicitly baked into the build system, with tool-assisted user-written bazel rules.
Discussed at the time:<p><i>C++ Modules Might Be Dead-On-Arrival</i> - <a href="https://news.ycombinator.com/item?id=19015079" rel="nofollow">https://news.ycombinator.com/item?id=19015079</a> - Jan 2019 (193 comments)
Do C++ folks still not have the equivalent of Turbo Pascal Units (which were from 1987)?<p>I can compile almost anything short of rebuilding my IDE in less than a second, every time, thanks to units in Lazarus/Free Pascal.
Eh, the assumption here is that you don't know what the dependencies of a C++ file are before you start compiling. That's not a great assumption.<p>That assumption allows you to write really lazy Makefiles. You just throw a bunch of C++ filenames in your Makefile, add the correct dep flags, and add an "include" line, and your Makefile will correctly rebuild the object files when header files change, without needlessly rebuilds. Here's how such a lazy Makefile works:<p><pre><code> CXXFLAGS = -MF $*.d -MMD -MP
-include $(wildcard *.d)
</code></pre>
Sure, that's nice, but there are a lot of reasons why you might want a more sophisticated build system than a lazy Makefile. You might have a project with long build times, so you might want a good build cache. You might have generated header files. As your project gets larger and more complicated, the idea of building everything with a Makefile really loses its appeal, and you look for better build systems.<p>The new generation of build systems is Bazel, Buck, Pants, Please, Meson, etc. Plenty of choices to go around. These systems require that you specify the dependencies up-front, rather than relying on -MF & friends. This means that if you add a generated header somewhere, nothing breaks. If you add a new file earlier in the include search path with the same name as a file later in the path, nothing breaks. (By "nothing breaks" I just mean that your incremental builds and clean builds will still both generate the correct output.) The -MF option is then used to trim the dependency set (in a particular way to keep the build correct... rather than record the header dependencies, you record which headers were <i>ignored</i> during compilation).<p>With these build systems, modules are going to work just fine.
Does anyone know of a good example of C++ module usage out in the wild? Not Hello World examples, but I mean an actual project with a serious build process using it? I'd love to see how they're currently used.
Okay, this was a convincing and persuasive argument.<p>Did anyone ever respond to this? What do the anti-SG15 (and/or pro-module) people say? I want to see the other side of this argument.
D's module system benefited greatly by getting rid of the preprocessor. I implemented precompiled headers for C++, and so knew that a robust and successful module system wasn't compatible with preprocessing.
How does this design handle cyclic dependencies? Or it doesn't, which would be even worse than headers in which you can at least forward declare some things?
it is<p>- no circular dependency allowed<p>- you have to fw declare everything, yet again<p>i gave up on C++ personally, for a little while i went back to C only, now i only use D, and some GO for my backend needs
How do C++ programs / programmers enforce and manage modularity in the general sense if they don't even have simplest module system? I'm not even talking of having module functors like Ocaml, but something like Rust has. It seems to be one of the most obvious steps to reduce complexity and compose program of smaller parts.