Boost logo

Boost :

From: Ulrich Eckhardt (doomster_at_[hidden])
Date: 2008-04-29 05:29:32


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk