Modules in C++

The last entries, about the best programming language ever invented by Bjarne Stroustrup, were about archaic things. Therefore, today there will be an entry about something new. About something that is just coming. About C++ digestion cancer and attempts to get rid of the pest.

Yes, I ask you, it will be short about modules.

There have already been many well-established opinions around the system for attaching „libraries” in C++. I don’t think mine will be deviating from the norm in any way.
This system is simply stupid in the world. But at the same time ridiculous. After all, few where the kopgo-pejsta method (at least at the conceptual level) is so widely used.

Problem

Directive #include this evil affects development in C++ in a decidedly unpleasant way. This is a fac
t. Anyone who has participated in a project larger than a few classes at least once knows the following problems:

• extended build time
• the need to use include guards
• „code fragility”

Let’s say you have a library in your project that comes in many places. Let it be X times.

So every time, X times, when you attach the header of this library to the work will be engaged preprocessor. The header itself, as well as any other header in the library, will also be paired. Like any header in each header that you attach to a library. It goes on. It takes a very long time.

What’s more, let’s say you make a small change to the header of this library. You run the build and watch as most of the project is just compiling again. You
might as well go to the kitchen for coffee/tea.

The fact that there are probably treatments to correct this problem – such as precompiled headers (e.g. https://github.com/sakra/cotire) but if you change our library, the project will be recompiled (to some extent, of course).

) but if you change our library, the project will be recompiled (to some extent, of course).

Let’s move on – who at least once had to correct the build by fixing the order of includów? Who ever corrected a double-underderlined guard?

All this, unfortunately, gives a rather sad picture of development in C++ – a tedious and long process, repeatedly the same actions. And about how easy it is to make a mistake, I do not need to convince anyone.

Solution?

A document (P0142R0) was submitted to the C++ Standardisation Committee to remedy this unfortunate situation.

This paper, as well as several more created on its basis, were the basis of the idea of modules in C++. The main assumptions of the modules (in a very simple way) are:

• no more separating code into headers and implementation
• improving build times
• enable libraries to be include on a theme basis
• increased granulation of imported libraries

How is all this going to be done? Ano, let’s look at a trivial example using modules (an idea taken from Nathan Sidwell’s „C++ Modules” speech at CppCon2018):

foo import;
std.core import

int main()
{ 
    std::cout < bar(42) < std::endl; //42
    std::cout < bar(1) < std::endl; //43
}

On the other hand, our sample module should look, more or less, as follows:

export module foo;
int acc = 0;
export int bar(int val)
{
    acc += val;
    return val;
}

It is worth noting:

• defining a module will be related to a specific syntax, where we should define what will be visible to library users
• module implementation details remain invisible to the library user
• when importing a module, we should only use its interface

The above are the most serious changes. They are rather simple to understand, so let me not comment on them more broadly.

A more interesting thread is changes invisible to the programmer at first glance – namely, according to the assumptions, there will be only one object file foo, each time the library is included will not result in the aforementioned load in the form of a preprocessor and parsing. Instead, a binary interface file will be used. It will be the responsibility of the creator of the library to provide the same.

The projected profit at compile rate should be about 20%. What’s more, you won’t have to think about what unique name to give to a header (include guard) anymore. You won’t need to separate the implementation from the header, etc.

Quo vadis?

So everything seems to be on track to make C++ developers feel at least a bit like the elite bunch of rust writers? But of course, in the world of C++ nothing can be too obvious and simple to implement!

As discussions are still ongoing on the final shape of modules in C++, it is uncertain whether this ficzer will appear in C++20 at 100%. All the information coming from ISO C++ confirms this assumption, although there is also no shortage of voices saying that this will happen only in C++23.

In addition, there are many problems arising from the current module assumptions (e.g. how to solve module mapping, module build order, whether to implement uniform module naming, expansion format for modules, how to approach the topic of backward compatibility, how to bite the subject of namespaces in combination with modules, how to distribute mod[tcp/ip, lokalne instalacje?]ules, and many others), which have not yet been defined by the standardization committee. Several important topics are still under discussion or initial implementation. Therefore, unfortunately, as of today, you can not be 100% sure what shape the modules will take in C++.

However, you can already test module implementations existing in clangu or msvc – both approaches (how else) solve issues not defined by ISO C++ in their own way, both approaches are different to each other, even at the syntax level used, but both amount to a reduction in build time.

If you would like to explore the topic of modules for C++ I strongly encourage you to use these materials:

• A module system for C++ – said document p0142
• Nathan Sidwell’s presentation with CppCon2018 about modules (the presentation itself takes about 0.5h, the rest is a discussion) – so basically these ~30 minutes are enough to understand, plus minus, the C++ approach to modules
• pretty good thread on reddit about modules
• current module implementation for MSVC and clang
• a little criticism of the discussion on the current state of affairs in modules in C++ (out of Corentin) part1 and part2