Explicit direct #include vs. Non-contractual transitive #include

Question

Say we have this header file:

MyClass.hpp

#pragma once #include <vector>  class MyClass { public:     MyClass(double);      /* ... */  private:     std::vector<double> internal_values; }; 

Now, whenever we use #include "MyClass.hpp" in some other hpp or cpp file, we effectively also #include <vector>, despite the fact that we do not need it. The reason I am saying it is not needed is that std::vector is only used internally in MyClass, but it is not required at all to actually interact with this class.

As a result, I could write

Version 1: SomeOtherHeader.hpp

#pragma once #include "MyClass.hpp"  void func(const MyClass&, const std::vector<double>&); 

whereas I probably should write

Version 2: SomeOtherHeader.hpp

#pragma once #include "MyClass.hpp" #include <vector>  void func(const MyClass&, const std::vector<double>&); 

to prevent a dependency on the internal workings of MyClass. Or should I?

I obviously realise that MyClass needs <vector> to work. So this may be more of a philosophical question. But would it not be good to be able to decide which headers get exposed when importing (i.e. limit what gets loaded into the namespace)? So that each header is required to #include what it needs, without getting away by implicitly including something that another header needed down the chain?

Maybe people can also shed some light on the upcoming C++20 modules which I believe address some aspects of this issue.

Answer 1

to prevent a dependency on the internal workings of MyClass. Or should I?

Yes, you should and for pretty much for that reason. Unless you want to specify that MyClass.hpp is guaranteed to include <vector>, you cannot rely on one including the other. And there is no good reason to be forced to provide such guarantee. If there is no such guarantee, then you rely on an implementation detail of MyClass.hpp that may change in future, which will break your code.

I obviously realise that MyClass needs vector to work.

Does it? Couldn't it use for example boost::container::small_vector instead?

In this example MyClass needs std::vector

But what about the needs of MyClass in future? Programs evolve, and what a class needs today is not always the same that the class needs tomorrow.

But would it not be good to be able to decide which headers get exposed when importing

Preventing transitive inclusion is not possible.

Modules introduced in C++20 are a feature that may be used instead of pp-inclusion and are intended to help solve this.

Right now, you can avoid including any implementation detail dependencies by using the PIMPL pattern ("Pointer to implementation"). But PIMPL introduces a layer of indirection and more significantly, requires dynamic allocation which has performance implications. Depending on context, these implications may be negligible or significant.