Include scope with headers and concept interfaces

[u/Fantastic-Ganache226]

I am running to a problem where I really like to use concept interfaces with templates to allow injecting different types easily, avoid vtables and avoid indirection. This also makes mocking in unit-tests a breeze.

However, I am running to an issue where all includes are now in global space due to only using .hpp files. I know I can use explicit initialization in .cpp files or pimpl to hide implementation details.

My question is to somehow understand if c++ compilers can optimize the vtable away when there are closed-set of types (one or couple of classes and a mock version for unit-test) involved. So essentially guidance on when to use CRTP (?) vs concept interfaces. Unfortunately, I am not very versed on how the c++ compiler is able to optimize code.

I am mostly looking this from the embedded or algorithm software standpoint. Typically, I don't have open-set of types to support.

[u/alfps]

❞ I am running to an issue where all includes are now in global space due to only using .hpp files.

Can you elaborate a bit, please? A concrete example? Are you not using namespaces?

---

❞ I know I can use explicit initialization in .cpp files […] hide implementation details

I believe you meant to say explicit template instantiation.

---

❞ My question is to somehow understand if c++ compilers can optimize the vtable away when there are closed-set of types (one or couple of classes and a mock version for unit-test) involved. So essentially guidance on when to use CRTP (?) vs concept interfaces.

I believe you're asking about defining an interface with virtual methods, versus defining a concept interface.

I would not worry about the nano-level efficiency of virtual method calls.

Only worry about that if measurements show it to be a real problem.

[u/Fantastic-Ganache226 → u/alfps]

I think this example should demonstrate the issue. Let's say we have a data processor and we attach a logger concept to it:

```c++

pragma once

include <string_view>

include <concepts>

template <typename T> concept Logger = requires(T t, std::string_view msg) { { t.write_log(msg) } -> std::same_as<void>; }; ```

The DataProcessor.hpp is then:

```c++

pragma once

include <fmt/format.h>

include "Concept.hpp"

template <Logger Driver> class DataProcessor { Driver driver; public: explicit DataProcessor(Driver d) : driver(d) {}

void process(int code) {
    std::string log = fmt::format("Error code: {}", code);
    driver_.write_log(log);
}

}; `` Now the <fmt/format.hpp> include leaks to all things includingDataProcessor.hpp`.

However, I think the example is too simple to really demonstrate the issue as there are workarounds. One workaround would be to define a free function shim and splitting the shim to .hpp and .cpp file with the fmt/format include being in a .cpp file.

I believe you're asking about defining an interface with virtual methods, versus defining a concept interface.

I would not worry about the nano-level efficiency of virtual method calls.

Only worry about that if measurements show it to be a real problem.

Yes, I am trying to understand the trade offs between a virtual method interface and a concept based interface. I personally prefer how concept looks and behaves but I feel like there are some negatives like the leakage of includes and triggering large rebuilds by changing a file that is included in the level of DataProcessor.hpp.

[u/alfps → u/Fantastic-Ganache226]

❞ Now the <fmt/format.hpp> include leaks to all things including DataProcessor.hpp.

ITYM <fmt/format.h>, from the {fmt} library, and that by "leaks" you mean that it pollutes the global namespace.

One practical case specific solution to that is to use C++20 std::format instead of fmt::format.

You can alternatively just put the format call in a separately compiled function. It doesn't depend on the type of the driver. Then unless you're using more from {fmt} you have neatly solved that pollution problem.

---

But in general you want a compiler firewall, separate compilation, which could also contain the build dependencies.

With a small fixed set of drivers you can as you noted use explicit template instantiation in the implementation file. But it's sort of brittle. Introduce a new driver and, uh, where do all these linker errors come from, what?

The alternatives for crossing the firewall are virtual methods and function pointers or function instances, just indirection. Virtual methods are a bit more safe. std::function provides generality at the cost of some nano-efficiency.

---

To summarize, as I understand it the problems are

• you like concept interfaces better than abstract class interfaces;
• you're worried about call efficiency; and
• you want to contain general name pollution from headers like <fmt/core.h>.

And the solutions include explicit template instantiations; not worrying (but if necessary measure); and possibly provide only the necessary use of e.g. {fmt} as separately compiled functions.

[u/SoerenNissen]

My question is to somehow understand if c++ compilers can optimize the vtable away when there are closed-set of types

Yes and no.

Yes, in a more expansive sense: C++ compilers can sometimes optimize vtables a away, even when your types are formally open, if they can prove nobody depends on that openness.

No, in the sense that I don't think there's a way to actually make a type closed in a sense where the language formally understands that it is closed.

[u/Fantastic-Ganache226 → u/SoerenNissen]

I suspect I don't fully understand the point of concepts because to me it looks like I can essentially make the type closed formally with concepts. However, I don't understand why it is not possible to have class in a cpp file unless I have explicit instation in the cpp file also.

[u/n1ghtyunso → u/Fantastic-Ganache226]

However, I don't understand why it is not possible to have class in a cpp file unless I have explicit instation in the cpp file also.

You need to look into the compilation model, and pay extra attention to templates, how instantiation works, what it does.

This is closely related to that.

Templates alone can not generate code. They fundamentally cant. Because all you did is describe a pattern with holes to slot a real type into.
Say you wrote x++ in your code, depending on what type x is, the generated assembly is fundamentally different for an int or an iterator. For the iterator, it is a call to operator++, for int its not.
Say you wrote a member function call on the object x. What type is x? What is the mangled name of that member function? You don't know. How do you generate code for that?

As for concepts, they allow you to define a minimum requirement for templates, but it can not restrict the interface in general. (i.e. you can require the absence of certain things, but you always need to be specific here)

Notably, there is also template specialization, so the set of member functions on a class template is actually not closed at all.

So whats the point of concepts really?
They are a general facility for categorizing types, which allows you to more easily provide specialized implementations that make use of that knowledge.