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

From: Matthew Herrmann (matthew.herrmann_at_[hidden])
Date: 2007-04-03 20:18:17

boost-request_at_[hidden] wrote:
> ------------------------------
>
> Message: 3
> Date: Wed, 4 Apr 2007 01:28:33 +0400
> From: Andrey Semashev <andysem_at_[hidden]>
>
>   
> ...
>
> And in return I only get reduced compilation time and application
> binary size (the dll will still be needed to run and distribute, but
> in case of a quick update I may provide only a small-sized exe without
> the unaffected dll). Honestly, after all experience I had so far I
> almost always prefer header-only solution, where possible and
> reasonable.
>
>   
Hi All,

Just my 5c on this, but we are using Boost Build to manage our software 
build process. We use a lot of separate libraries and compile a lot of 
code, even for a large compiler farm. Using Boost Build, it is trivial 
to create and use libraries, including 3rd party libraries, that 
separately compile. I don't find it at all inconvenient to use static 
libraries because that build system is designed to work _with_ the 
object file model that C++ sits on, not around it.

I support the idea of header files for convenient use for new users, but 
for libraries that wrap evil C system headers with nice modern C++, its 
against the spirit of the task to still inherit all the macro and header 
ordering hell from the library I'm wrapping. And I don't care about 
optimising by inlining a call to flush to a slow disk.

The header-only approach just doesn't scale like object files -- imagine 
how slow our builds would be if we had to recompile all the I/O code in 
our operating system every time we wrote a hello world application 
because they'd made it header-only. The solution is not to put that code 
it in a precompiled header and waste memory, but to do what the O/S guys 
have already done: compile it separately and just expose the facade 
through the object file interfaces designed specifically for that purpose.

Of course template code is a different kettle of fish.

I add my vote for the hybrid header/non-header model, where possible. 
The people who are using build systems are also probably the people who 
care about build times and macro/header ordering hell. They'll be 
prepared to invest time to set up library compilation etc. to get what 
they want. Others working on smaller projects won't care and won't have 
to deal with the start-up hassles.

Best Regards,
Matthew

-- 
_________________________
Matthew Herrmann
matthew.herrmann_at_[hidden]