Module concept for C++ [closed]

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 11 years ago.

Improve this question

C++ is still an evolving language and new features are being added to it over the years.

One feature that I miss badly in C++ is a proper module concept: the current approach using header files (where you use a conditional #define to make sure that the header is not included twice) seems definitely unsatisfactorily to me.

For example, in my project we have the problem that w开发者_运维问答e have too many "#include"'s in many source files, making the compilation time unnecessarily long: it takes 45 minutes to build our product, using Incredibuild, i.e. using at least 10 cores in parallel. Therefore, we have to spend a lot of time cleaning up files manually, i.e. removing includes to check if they are really needed.

I think it would be very useful to have a module concept that makes it possible to

1. separate clearly the interface from the implementation of a module;
2. compile the interface and the body of a module separately (currently .h files are compiled again and again each time they are included in other files): a tool could then read the compiled interface and tell what types, functions, classes it exports;
3. write tools for automatically rearranging imports more easily (e.g. with Java / Eclipse it is possible to rearrange all the imports of a file automatically).

Do you think that it is possible to define such a module concept and integrate it into C++ or would that be too complex? Do you know of any efforts in this direction?

EDIT

Thanks for the suggestion regarding precompiled headers. I will try it out if possible (We use Visual Studio 2008). Maybe we are using header files in the wrong way(?) We use one header file for each class. Then we have a cpp file with the class implementation. Often we end up with cpp files that include 30, 40 header files. When we change the cpp file, some includes are not needed any longer, but it is difficult to find out which ones. This is partly related to the fact that header files include other header files.

We spend too much time rearranging the imports and it seems there doesn't exist a tool that can do this automatically. It would save us a lot of time.

---

C++ is still an evolving language and new features are being added to it as part of the C++0x development.

The C++11 standard has already been approved and published, so no more features are being added to it. Not for at least another few years.

One feature that I miss badly in C++ is a proper module concept: the current approach using header files (where you use a conditional #define to make sure that the header is not included twice) seems definitely unsatisfactorily to me.

Some compilers support #pragma once to avoid having to write the include guards, but it is non-standard as far as I know. There are situations where you don't want include guards; Boost.Preprocessor is an example of a library with some headers that intentionally don't have include guards.

For example, in my project we have the problem that we have too many "#include"'s in many source files, making the compilation time unnecessarily long: it takes 45 minutes to build our product, using Incredibuild, i.e. using at least 10 cores in parallel. Therefore, we have to spend a lot of time cleaning up files manually, i.e. removing includes to check if they are really needed.

Stroustrup has an FAQ entry on compile-time slowness. Also read up on GotW article #7 about including header files. It's highly likely that you're including way more files than necessary. For example, you may be able to get away with forward declarations. If you have huge header files, you may try splitting them up so that your sources include only the declarations you really need. It may be just a matter of your file structure not being conducive to fast compiles.

1.separate clearly the interface from the implementation of a module;

We have the PIMPL idiom (also known as a compilation firewall) for this. And even without it, I don't have any trouble putting the implementation in the .cpp file and the interface in the .h file (even though it's not a "pure" interface).

2.compile the interface and the body of a module separately (currently .h files are compiled again and again each time they are included in other files): a tool could then read the compiled interface and tell what types, functions, classes it exports;

Some compilers support precompiled header files that you can take advantage of.

3.write tools for automatically rearranging imports more easily.

I don't understand what you mean by this.

Do you think that it is possible to define such a module concept and integrate it into C++ or would that be too complex? Do you know of any efforts in this direction?

Believe it or not, there is a proposal to add some kind of module concept to C++, but it hasn't been accepted into C++11 due to time constraints (they were working and reviewing other proposals like rvalue references, which in my opinion, is much more important). It might be included in the next version or update of the C++ standard.

---

That's not how C++ is designed to work. You could probably do it if you poked and prodded the linker enough to read an index file instead of reparsing headers. However, your compiler should only be compiling files that have changed or have dependencies that have changed anyway. And besides, headers are not really 'compiled' into meaningful code (unless they have implementations in them, which is correct in some cases). They're just a note to the compiler that that token will be found later when linking.

Short answer: No, you should not try to implement some home-brew 'module' system. I really doubt header files are what is taking forever anyway unless you're using them incorrectly.

Edit: As someone pointed out, I was neglecting header files that may actually have something to compile, which is usually the case in large libraries or anything that uses a lot of templates. As such, I was wrong on the "really doubt header files are what is taking forever" statement.