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

From: Jeff Garland (jeff_at_[hidden])
Date: 2007-04-02 11:41:23

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.

Alexander Nasonov wrote:

> IIRC, someone asked recently why asio requires -lboost_system at link time.
> 
> In my personal opinion, C++ wrappers for OS services should not be header-only. 
> I would prefer asio, process, shmem and the like to be all consistent with 
> boost.filesystem. Opinions?

I think they should, if practical, have an option to be used as header only. 
   Implementations should be put in .ipp files and controlled by a macro like:

   BOOST_ALLOW_ALL_HEADER_WITH_SYSTEM_INCLUDES

If you don't add this macro then you have to link the library -- otherwise 
it's header only. I realize it's a bit more work for the library developers, 
but that way we can have it both ways.  I see this as like having an 'all 
inclusive' header for a library even though there are more granular headers -- 
it makes it easy to get started and it actually handles the majority  of the 
cases where people don't care about optimizing 'include performance'.

Jeff