Martin Bonner wrote:
----Original Message---- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener Sent: 03 April 2007 23:31 To: boost@lists.boost.org 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.