From: Matthew Herrmann (matthew.herrmann_at_[hidden])
Date: 2007-04-03 20:18:17
> 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
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.
-- _________________________ Matthew Herrmann matthew.herrmann_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk