From: Nicola Musatti (Nicola.Musatti_at_[hidden])
Date: 2007-04-02 13:15:06
Jeff Garland wrote:
> Sohail Somani wrote:
>> Oh gosh yes. Having things in headers because it makes it 'easier to compile' hurts compile
>> times in the long run.
> Get a faster build machine and/or use pre-compiled headers -- really.
>> Its just not good practice and I suspect a non-empty subset of new
>> boost users are also new to C++.
> 5 years ago I believed it was a serious issue too -- I've substantially
> changed my mind. And not in small part by using asio (and other boost libs)
> as header only. It's extremely nice to not need to figure out how to build
> and link. You can get started with so trivially with an all header library --
> and I think that frequently it's trouble getting over that first hump that
> stops people from using libs. So if the barrier is lower more people will use
> the libs.
Sorry, but I disagree. The effect of header only libraries on build
times is still unacceptable and not everybody can convince their bosses
that they need more powerful machines every six months or so.
One of the mistakes I came to regret most in the project I'm working on
is to have a very small template metaprogram in a header that's used
just about everywhere. But I learned my lesson and now I'm happy that I
hid Boost.DateTime behind a class of my own.
Note that we're using Borland's compiler, which is considered a very
fast one and that we do use pre-compiled headers; this, by the way, are
not a panacaea, among other things because a sizable portion of your
savings in sheer compilation time is lost in much increased dependency
As to binary libraries stopping people using Boost, I don't think that's
much of a problem per se: after all people programming in C++ and C have
been accustomed to static and shared libraries for ages. Rather what may
constitute a problem is the complexity and general unfriendliness of the
Boost Build system.
Still, the time taken to find out how to build libraries for one's own
use is mostly spent once, and can be delegated to a single team member;
excessive build times impact the whole team all the time.
One instructive exercise is to run g++ -H -P -E on a C++ source file
chosen at random; it doesn't even need to use Boost, it's sufficient to
include, say, <vector> on Windows. The resulting tree of included
headers is disenheartening and a clear symptom of what I consider a very
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk