Re: [boost] [system] Why is this not header-only?

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.