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".
Right.
>
>> 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
reusability.
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.