From: Edward Diener (eldiener_at_[hidden])
Date: 2007-04-04 09:50:06
Martin Bonner wrote:
> ----Original Message----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Edward Diener Sent:
> 03 April 2007 23:31 To: boost_at_[hidden]
> Subject: Re: [boost] [system] Why is this not header-only?
>> I think that the general reason for putting code in a library rather
>> than a header file has not been touched upon, and that is that header
>> files will have inline code as opposed to a library.
> It will have lots of functions that are declared "inline".
>> It is quite possible that inline code is not an issue and that the
>> tradeoff of greater size for the slightly faster speed of inline code
> Are you under the impression that having functions declared "inline"
> means that the compiler will always inline them? Certainly for the
> compiler I use (Visual C++) this is very far from the case. It will
> inline small functions, but doesn't bother for larger ones. This does
> mean the same function is present in many object files, but there will
> be only one copy in the final exe (or rather, one copy in each exe and
> dll that uses the function).
Thanks for the heads up. I was too quickly and erroneously thinking that
functions in a header file, as opposed to a .cpp source file, were
automatically "inline". That comes from my own practice with
non-template code of always putting function declarations in header
files and their definitions in the .cpp source files, and never putting
code in header files. Now I realize that putting code in header files,
for non-templates, is the equivalent of adding .cpp files to a compilation.
In this header file distribution model for non-template code, one is
adding the code to each module using it, somewhat like a static library,
as opposed to sharing it in a separate shared library if it uses common
code. I still prefer the latter for non-template code when it comes to
I do not think the problem in Boost has been an all header file
distribution versus a mixed header file and library distribution so much
as it has been the fact that building libraries via bjam has led to
problems with certain distributions. Perhaps with version 2 of the build
system along with better documentation in using it, most of the
previous problems will go away.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk