views:

45

answers:

3

I've read a few of the articles about the need / applicability / practicality of keeping headers around in C++ but I can't seem to find anywhere a solid reason why / when the above should or should not be done. I'm aware that boost uses .hpp files to deliver template functions to end users without the need for an associated .cpp file, and this thought is partially sourced off browsing through that code. It seems like this would be a convenient way to deliver single file modules of say a new Wt or Qt widget (still sticking to the one class per .h convention).

However are there any negative technical implementations for giving somebody a single .hpp file with both the header declaration and implementation assuming you have no problem with them having access to the implementation (say in the context of OSS). Does it for instances have any negative implications from the compiler's / linker's perspective?

Any opinions or perspectives on this would be appreciated.

+4  A: 

'm aware that boost uses .hpp files to deliver template functions to end users without the need for an associated .cpp file

Wrong verb: it’s not “without the need”, it’s “without the ability”.

If Boost could, they would separate their libraries into headers and implementation files. In fact, they do so where ever possible.

The reason for a clean separation is simple: compilation time for header-only projects increases tremendously because associated header files have to be read, parsed and compiled every time you recompile the tiniest part of your application.

Implementation files only need to be compiled if you happen to recompile that particular object file.

Large C and/or C++ projects take hours to compile. And these use a clean separation into header and object files. If they would only use header files, I’m betting the compilation time would be measured in days instead of hours.

But for many of Boost’s libraries, the fact is that template definitions may not reside in a separate compilation unit than their declarations so this is simply not possible.

Konrad Rudolph
Ok, I figured there was some sort of linker / compiler rabbit hole that would prevent you from being able to do this cleanly.I was hoping there would be some sort of ifdef magic to prevent these kinds of issues for convenience sake.
wildcarde
A: 

The major negative aspect of .hpp-only libraries is that they cannot refer to a precompiled module. All of the code present in the .hpp and hence all of the code in the library must be added to your application. This increases the size of the binary and makes for redundant binaries on such a system that uses the library more than once.

Reinderien
couldn't this be solved with an ifdef set or is this functionally different because of the behavior of the include command and it's general behavior to copy things?
wildcarde
Unfortunately this can't be solved with an `#ifdef`. It's inherent. `.cpp` files get compiled to object files that can then be compiled to libraries that can be reused. Any code in `.hpp` files must be compiled into your own application binary. The advantage is that this allows for higher performance using inlining, if you have a decent compiler. The disadvantage is bloat and redundancy.
Reinderien
This makes it sound like this could be useful for things other than what I'd originally been considering, and unfortunately not at all useful for how I'd been considering it. Thanks for the information!
wildcarde
+1  A: 

With templates you have no real choice. In theory, export allows you to separate the interface from the implementation, but only one compiler (Comeau) really supports this1, and it's being dropped from C++0x.

In any case, trying to put the implementations of non-template functions into headers leads to one obvious problem: the One Definition Rule remains in effect, so if you define the same function in more than one translation unit, you have a problem. The linker will typically give an error saying the same symbol has been defined more than one.

1Though it's mostly the EDG compiler front-end that really supports it, so other EDG-based compilers, such as Intel's also support export to some degree, though they don't document it, so you can't depend on much with them.

Jerry Coffin
@Jerry: the ODR problem however can be solved trivially my making the function `inline` or putting it into an anonymous namespace (or marking it `static` but I guess this practice is deprecated).
Konrad Rudolph
@Konrad: true, but those are *lousy* fixes unless the function(s) in question really is/are really suitable for inline expansion. Otherwise, you can end up duplicating large functions for each TU, leading to pointless code bloat (though it is true that the linker *may* be able to merge them; many have added this to help keep duplicates introduced by templates from leading to bloat).
Jerry Coffin