When using C++ modules, is the any reason to separate function declarations (.hpp files) from their definitions (.cpp files)?

Question

I'm used to writing code without modules where the header files contain the function declarations like:

// foo.h 
class Foo
{
    void bar();
};

and the corresponding .cpp file contains the definition:

// foo.cpp
#include "foo.h"

void Foo::bar()
{
    // ...
}

To my knowledge, this is done to decrease compile time and reduce dependencies . When modules will be used, will this still apply? Would it be just as fast to have the class in a single file with the definitions the way Java and C# does it? If this is the case, will there be any need for both .hpp and .cpp files when using modules?

Answer 1

The only reason I'm aware of, as the modules proposal currently stands , is to handle circular interface dependencies.

If a program is made up of modules and it does not separate function declarations from definitions, all module files will be module interfaces (as opposed to module implementations). If you want to compare them to header and code files, module interfaces could be seen as the header (.hpp) file, and module implementations could be seen as the code (.cpp) files.

Unfortunately, the modules proposal does not allow cyclic module interface dependencies. And since your program is now completely made up of module interfaces, you will therefore never be able to have two modules which depend on each other in any way (this may be improved by the proclaimed ownership declaration in the future, but this is currently not supported). The only way to resolve circular module interface dependencies is by separating declarations and definitions and placing the circular imports in the module implementation files, as opposed to circular module interface dependencies, circular module implementation dependencies are allowed.

The following code provides an example of a situation that is impossible to compile without separating declarations and definitions:

Foo module file

export module Foo;

import module Bar;

export namespace Test {
    class Foo {
    public:
        Bar createBar() {
            return Bar();
        }
    };
}

Bar module file

export module Bar;

import module Foo;

export namespace Test {
    class Bar {
    public:
        Foo createFoo() {
            return Foo();
        }
    };
}

This article shows an example on how this could be solved were the proclaimed ownership declaration available. In essence, it comes down to separating declarations and definitions.

In a perfect world the compiler would be able to handle this scenario, but alas, as far as I'm aware the current proposed implementation of modules does not support it.

Answer 2

There is a nice discussion here that explains the idea of modules.

In short you are right, the separation between header files and implementation files will no longer be needed. The #include directive will be replaced by the import directive, and at compile time the module will provide the required information that would otherwise be in the included header file.

Answer 3

There are still lots of reasons to use header files.

The ease of sharing and understanding an object api without seeing the underlying details is of enough use to keep them around. It's a good 20 ft view of an object, essentially being an outline.

If you are selling a library, you would include a header file, as well as an archive file or a shared library. This way you can keep information proprietary without compromising the IP of your product, and your customers can include a binary compiled for their target.

I don't believe this is possible without header files.

Answer 4

Another use of this idiom is inherited from C; it is a convenient means of forward-declaration even for translation units that have no dependencies on other translation units.

The use of precompiled headers didn't really become an important thing until C++'s expanded use of header files made it necessary for performance reasons (notwithstanding some very large old school headers like windows.h).

The idea does seem to be to bring something more like the C#/Java mechanism into play. The C++ mechanism is very Modula/ADA in spirit. It would be nice to have the machines do more of the work for us.