It is quite common to separate C++ code into cpp and hpp files and to define the hpp files as the interface of the code. Therefore, when you use the code as a library, you can expose the interface, but offer the rest as a compiled library. It also allows to separate different components of the code in a way that one component can access other components' interfaces without needing access to the core code (and potentially need access to all its dependencies).
Are there any reasons why interfaces should not contain cpp files?
I could put the cpp code into the hpp file of course, but if the file contains a lot of definitions, those would be copied by the preprocessor for each #include of that file.
My first instinct was to keep the files separate and use both the hpp and cpp in the interface.
One issue I could imagine is this:
If I compiled my component to a lib, then the interface cpp would be compiled into the lib as well, but it would also be shipped as part of the interface. I tried this with a minimal example and the linker does not complain about having a definition in the cpp and the same definition in the lib.
So apparently this could lead to problems if the cpp and the lib were to become inconsistent. In my minimal example, the compiler uses the version from the cpp and not the one compiled into the lib, so this could become a problem of expected behavior: The recipient of the interface would get what they see in the cpp file, but the person who compiled the lib could have had a different behavior in mind.
This makes me think that having cpp files in the interface is inherently dangerous. Am I right with this line of reasoning or are there examples where it makes sense to do this?