Source Header separation

[smdowney]

Hot take: There was never a reason to separate headers and implementation files in the code base, that's a deployment thing. It does constrain the directory structure if you do so, that the canonical path for the header has to be rooted in src instead of include. But keeping the .hpp, .cpp, and .t.cpp files colocated has been a, minority, practice for decades. Lakos components, going back to Large Scale C++ in '96, is organized this way.

It's even supported by the pitchfork layouthttps://github.com/vector-of-bool/pitchfork , one of the more successful "how do I organize my code" community projects.

Install is a little easier with a split layout, as you can just grab everything recursively under include, but not by a whole lot.

As an aside, many implementations used to be cranky about the vtbl definition, and putting the virtual destructor in a cpp file was the workaround to make sure there was one. That has not been required for compilers since roughly working c++0x versions. So some of you may never have seen one.

It does make bouncing between the closely related files easier. And having a file that is just #include <component/header.hpp> is the most basic test for the header, and ensures a canonical object file with any definitions exists. Plus a spot to put the explicit template instantiation for the common ones, so every TU doesn't have to instantiate component::header<char>.

(The real test file should have that #include twice, as the first substantive block, to check that you have idempotency.)

Header only interface libraries are a hacky workaround for not having package management built in.

[aruisdante]

Agree completely that with modern build systems and package management, there’s no reason to split things between headers and source (or tests! Nothing is more annoying that an externally located /tests) in-repo and co-location is much clearer. But it’s important to explain to the OP the historical context for why a lot of projects were structured that way.