On Sunday 27 April 2008 19:08:24 Roland Schwarz wrote:

Please don't misunderstand this mail. I do not want to start a header contra lib war. I just want to learn about the pro's and the contras of header only.

The issue has popped up in this list quite some times, but I was not able to find any document which tries to do a serious in-depth discussion of when to header only and when not.

If anyone knows about such a document I would be pleased if he could point me at it.

Not sure if it exists, but there is one main difference I see: All code is always compiled. From that follow a few things: 1 You don't have any problem with changing ABIs. In particular, you don't need precompiled code for the various different compilers or even different compiler settings, which can all generate code that is incompatible with the other settings or compilers. 2 You always recompile the whole code. 2.1 Always recompiling might be a significant performance overhead. In particular code that is completely included by headers suffers from this. 2.2 You are effectively linking statically, with the typical drawback that you can't share code between different executables like with a shared library and that you can't replace the code for bugfixing without replacing the whole application. 2.3 Unused code is easier discarded by the compiler. If you only need a small subset of the provided functionality, the unused part could still cause overhead when it is loaded as a shared library. Note that this is also the case for traditional static linking. 3 Too deep inline expansion might cause bloat in the executable size, in particular when everything is header only. This depends on the compiler though. 4 Inline expansion and interprocedural optimisations might make code both smaller and faster. IPO is typically not available when the library is linked as a shared library. Note that other than the header-only approach and the traditional static or shared libraries, you can also create an ad-hoc static library by simply including the necessary .cpp files into exactly one translation unit of your executable. This works around the ABI problem but keeps the compile times and code size reasonably low. Note that Boost doesn't support this mode at the moment, but I think I'm going to implement this and also push it upstream soon. You can vote for me. ;) cheers Uli