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

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2007-04-03 20:30:13

On Wed, 04 Apr 2007 10:18:17 +1000
Matthew Herrmann <matthew.herrmann_at_[hidden]> wrote:

> 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 

Wow!  and I mean it.  I tried using Boost.Build as the base for a new
build system, and I could not get anywhere at all.  Do you have anything
you could share?  the system tiself, any docs, best practices, wiki,
anything at all?

I ended up wrapping the boost bjam stuff with a makefile that setup
stuff and generated what I wanted.

I would LOVE to get in-the-know by someone who's actually used that
system for something other than building the out-of-the box boost.

> 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.

I agree with this as well.  In fact, I played with asio to get it to get
rid of the header-only implementation.  Soem tricks and you can even
eliminate the IOCTL constants.

> 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.

I agree with this as well.  Compile times are a huge time sink.  We
build on very fast, modern machines with at lesat 2-4GB RAM, and
compiles take a very long time.

> Of course template code is a different kettle of fish.

Yeah... compile times are the biggest reason some of our algorithms are
NOT template/generic.