C++ Modules Might Be Dead-on-Arrival (2019)

C++ modules have little to do with the concept of "modules" you find in other languages. You can think about it as a more standardized way to define and create what is known as pre-compiled headers. But that's basically it.

C++ is not alone in this regard, take .NET as one of the ecosystems that follows the same idea, D, Ada and Fortran as well.

> Wait, does the C++ module proposal allow modules names to be different from their filenames?

It sort of makes sense. The calling program specifies `foo.bmi`, but compiling for ARM might look in "armv5/foo.bmi" while targeting x64 might look in "x64/foo.bmi", and that doesn't even take into account that there might be different debug and release versions.

Go allows it too. Traditionally the module name is the same as the directory it's in, but that's no longer true with versioned API modules.

There is really nothing to see here. The "(2019)" should clue you in.

There are lots of ways to skin this cat. C++ has what they call a "large installed base" -- i.e., literally hundreds of billions of lines of code in active use. So, the solution for C++ is not what we might have done for a new language. It had to be reasonably easy to move an existing project to modules without breaking everybody that might depend on it, and without needing everything you depend on to be moved already. Everybody has their own upgrade schedule, many of which must be "never".

So, it looks odd compared to a green-field approach, but it works and is not a burden to maintain, which is what matters.

D just reads and compiles each module only once, no matter how many times it is imported, or whatever rat's nest the import graph is.

Modules could be precompiled, but I found that it was faster (and easier) to just recompile them.

(And not having a preprocessor eliminates several passes.)

If the compiler and the build system is an integrated product, then right, this shouldn't be too hard. But that's not usually the case.

If they're not, what's the interface for the initial build step? Is it still something like "gcc -MD"? But "gcc -MD" can't just spit out a list of files. It will have to output not only file names but also module names (both referenced and declared), because resolving module names to file names requires global knowledge.

That means every build tool that wants to work with C++ must be changed to take in this extended information and resolve module dependencies. Because otherwise, if there's even a single module in your 1339 file project, then current tooling breaks.

Which will put pressure on developers to not add that first module, slowing adoption.

Year added above. Thanks!

Visual studio support is mostly there: https://devblogs.microsoft.com/cppblog/moving-a-project-to-c...

CMake support is an open issue: https://gitlab.kitware.com/cmake/cmake/-/issues/18355

The module system from that video would have been great; there was/is a sound implementation that is based on Objective-C's module system, has been battle tested extensively and works without all kinds of silly quirks, makes packaging and distributing modules relatively easy, and provides performance benefits similar to precompiled headers which are known to improve build times substantially.

Of course, for those reasons it did not get standardized and instead what did get standardized was a mostly theoretical module system that has a great deal of ambiguity and implementation divergence across different compilers, places a great burden on build systems, none of which fully support modules yet, does nothing to help with packaging libraries, and only sometimes provides performance benefits, sometimes provides performance regressions.

Such is the way of C++, a language whose standardization process has been hijacked by politics and corporate stacking of the committee, legacy interests who insist on holding back key features that would improve the language for the vast majority of developers for the sake of ABI compatibility, and whose advancement has been plagued by numerous defect reports and broken or buggy features that get adopted without any kind of battle testing, user experience or broad community feedback.

> Do C++ folks still not have the equivalent of Turbo Pascal Units (which were from 1987)?

Well, it's an easy problem to solve when a single compiler is used for everything. I doubt that Turbo Pascal Units could be used with other Pascal compilers.

With C++, your module compiled with Clang might be used in a program compiled with gcc. I don't think that C++ modules specify a binary interface in the spec.

With new languages it is easier to implement modules, because a new language, by definition, only has a single implementation. If the new language specifies a modules system it does not break existing software because, by definition, it is a new language.

> I can compile almost anything short of rebuilding my IDE in less than a second, every time, thanks to units in Lazarus/Free Pascal.

I know, I sometimes use Lazarus. I'm not really sure that a FreePascal Unit is compatible with other Passsl implementations (maybe Delphi, because the goal is to be a drop-in replacement for Delphi?).

My understanding of the C++ modules specification is that there is no requirement for modules from different compilers to be compatible.

Yes, modules finally, although not without issues, as the stardard is freshly baked and there are 40 year of history to drag.

On the context of Turbo Pascal units (actually they are UCSD Pascal units), C++ Builder did support the concept of C++ packages with a similar purpose.

Or if one wants to delve into the COM dungeons on Windows, that is also a path although naturally the COM ABI only covers the basics of an OOP ABI.

Visual C++ support for modules is already quite good, although still has some warts.

These are from 2006~, extensions for a language (SourcePawn) took over in 2009. http://www.metamodsource.net/plugins

Nothing serious, but you can look at

https://github.com/pjmlp/ppm2png

https://github.com/pjmlp/AStarDemo

I am also in the process of porting Raytracing Weekend to C++ modules.

Yea, it's a build system. The same problem exists with lots of projects.

    // foo.cpp
    #include auto_generated_file.cpp

The C++ compiler doesn't know how to build auto_generated_file.cpp, the build system does.

From my perspective, all the complaints are solved by using a more modern build system, like Bazel. If you are already encoding dependencies between modules in your build system, then when you are searching for an import, it's trivial... you just look at the declared module dependencies. Bazel (and other similar systems) already force you to do this for other reasons, and so you theoretically get modules "free".

It's not like the same problem doesn't already crop up with generated sources. Like, if you see this:

    #include "file.h"

If file.h is generated, then your build system needs to generate it before you compile anything that includes it. Generated sources are a major pain point in C++ build systems. It throws a wrench in the typical compilation flow... where you don't know which header files you need until you run the compiler, so you have to manually specify header dependencies in your Makefile if any are generated (instead of getting the dependencies from the compiler output). To keep things consistent (and more reliably cacheable), in Bazel, you have to specify all the dependencies in your build system, not just the ones that the compiler can't figure out for you. This solves some other problems with cached builds--like how you can have multiple files named "file.h", and the insertion of a new file earlier in the include search paths should trigger a rebuild, or else you end up with a poisoned build cache.

Obviously there are going to be some people stuck on build systems that can't handle this stuff gracefully. Too bad. You can keep using headers, it's not like those are going to stop working.

Edit: I just notice now that you said "TU", my mind autocompleted your sentence with "file" instead the first time I read it. Still keeping my comment here, module :private is not well known and a nice way to declare a distinct interface Translation Unit while keeping everything in one file.

You can do this, but you can also use the "module :private" fragment if you want to have everything in one file while still keeping the distinction between interface and implementation.

Example:

  // File "mymodule.ixx"
  module;

  #include <string>

  // declare interface
  export module mymodule;

  export namespace mymodule {
      // templates have to be declared
      // in interface to be known at
      // compile-time
      template<typename T>
      T add(T x, T y) {
          return x + y;
      }

      std::string greetings();
  }

  // implement interface
  module :private;

  std::string mymodule::greetings() {
      return "hello";
  }

You can do that if you wish, they are called module interface units.

#include and namespaces.

Mostly we rely on the system package manager. If I'm trying to compile a C++ program and I need somelib I `sudo apt install libsomelib-dev`

Works about 80% of the time. The other 20% I gotta go digging through either github or sourceforge or someone's personal website that hasn't been updated in 15 years.

It's not "enforced;" it is managed through various means including namespaces, header includes, and prefixes. For example, SQLite is a library whose functions all start with 'sqlite3'. In practice it works well enough: name collisions are uncommon and can be managed.