A Few Words on C++ Modules

Dmitry Guzeev
6 min readJan 8, 2018


Screenshot from the CppCon 2017 talk

C++ Modules is, certainly, one of the most anticipated C++ programming language features. All modern C++ developers (if you aren’t talking about people who writes all of their code in C and Assembly Language) do, indeed, think that using current #include system for the modularity system implementation in C++ is, just, stupid: We are not in 80s anymore! Every modern language has modules. I personally think that C++ should also have them.

We are introducing functional programming concepts to C++ every standard, that’s definitely cool. But, however, modules are also important! Nothing was done for modularity system since the first C++ release. Nothing! That’s terrible.

This post will serve as an introduction to C++ modules. In particular, it will:

  • Tell you about the motivation on the C++ Modules TS.
  • Enumerate the benefits of the features of the new TS.

I won’t provide any kind of syntax explanation, however. Why? Well, modules aren’t standardized yet, and, hence, talking about syntax won’t be anything useful. At all.

No header files anymore

That’s a huge one: You won’t be required to separate your files into header & source parts.

Just think about that: The amount of files in an ordinary C++ project will half!

It also makes C++ a little bit easier for newcomers. Now, I don’t believe in the fact that header files is the most difficult part of C++, — they really aren’t. But, however, absence of those crappy C things will make C++ more understandable for people who are just beginning their way in C++ learning.

We need to make things easier in order to increase our C++ community! That’s important!

Declaration consistency

We can deduce a way more better fact from the previous paragraph: There will be no declaration order consistency problems anymore.

What I am talking about? I don’t know if you are like me, but, the one biggest thing I can’t stand about C++ is that it requires me to follow it’s “declaration vs. definition” principle: You will, in any case, be required to repeat yourself, if you want to develop a C++ project which consists of more than one file.

Do you want to see an example? I don’t, — it’s awful. But, however, I will show one here in order for you to see the real problem.

Let’s take a Cat class as an example, - I love using cats for my personal profit (that's joke).

Now, there is a couple of problems with the code above:

  • You need to specify include guards.
  • There is no way to know which access specifier does a particular method have if you are only looking at the source file (“cat.cpp”).
  • Signature of every actual method needs to be specified twice.
  • It is better to keep the order of declaration consistent (this way you will have better code navigation possibilites), and, hence, you need to keep track of it, which is just redundant work you need to do.

The genuine design of C++ breaks DRY principle and makes you to do redundant work, — that’s inacceptable.

Better compilation times


Compilation times are promised to become smaller up to 20%. This is the consequence of the fact that there will be no need to read and process all of those #include statements each time compiler sees it.

Do you want an example? I will write a simple hello world application and ‘ll compare the sizes of the actual program we wrote with the preprocessed version of it (version of program which has all of it’s #include's resolved).

Let’s look at the “fake” size of our program:

"Fake" source file size

As it can be seen from the picture, the size of the program we wrote is only 95 bytes.

Now, let’s compare the above results with the preprocessed version:

"Real" source file size

We can see that, oh my goodness, preprocessed file is huge: it takes 644K (658905 bytes). This is incredible and insane.

And, nonetheless, this is only a hello world application. Just think how much more stuff should be processed by a C++ compiler when compiling a normal ~10k SLOC project. Unimaginable.

Package management

It would be much easier to implement and standardize a package management system for C++ with Modules TS.

And, I want to note one thing here. C++ compiled nature is not the reason it doesn’t have a good package manager yet (take, Rust, for example). “Module” concept absence is to blame. Really.

There were many tries for the achievement of a sane package manager for C++. Let me name a few of them:

None of them became the standard of the C++ world, obviously.

Preprocessor usage elimination

This TS can result in the huge usage reduce of one of the most used preprocessor directive today, which is, clearly, the famous #include thing.

I know that C preprocessor is a good thing and it has a lot of advantages for C++, but, however, replacement of the preprocessor will make language easier and cleaner.

Module include statement order

The order of new import statements (from the Modules TS) will not matter. At all.

Why should you care?

Well, let me put an example right here.

Say, for example, you want to use two (absolutely unrelated) libraries in your C++ project. The first library, which is called “Cat”, contains the definition of the class “Cat”. Second one, let’s call it “Clear Absence of Trampoline” (or, simply, “CAT”), contains something else (I don’t know how to create names for software products).

Now, the “Cat” library contains a #define'd option CAT_PRINT, which, if enabled, adds the Cat::print() method to the Cat class definition:

It happens that the second library, abbreviated “CAT”, also has an option CAT_PRINT which, in fact, is responsible something completely stupid you don't want to be enabled ever.

Guess what? You need to choose. What you’ll do? Well, you might throw out one of the libraries, and either implement one yourself, or, maybe, find another library which has similar functionality.

That’s a problem. We don’t want to have such things inside C++!

Where can I try it out?

C++ Modules TS was promised to standardized in C++17 standard, but, however, it didn’t actually happen. Instead, what everyone talks about right now, is the C++20 Modules standardization. It would be really nice if it really happened.

There is a few possible approaches for the new module system implementation:

The first one is more popular than the second, but, probably, the resulting implementation would be the result of the merge of two.

The compiler support is very poor and experimental at this moment.

Modules feature was announced available in VS 2015 Update 1 and there were some updates on that topic in the May 2017. I don’t personally use Windows, and, therefore, I can’t say anything about the VS implementation real usage.

CLang 6 also has experminental modules support.


There are some resources to follow if you are interested in C++ Modules:

Leave your thoughts and ideas about this TS in the comments, if you like. I will continue to be interested in C++ modules, and, therefore, I will post updates on this. Have a good day!