Re: [boost] Hybrid compilation model? was: [system] Why is this not header-only?

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2007-04-06 20:43:21

On Fri, 06 Apr 2007 10:57:06 -0400, "Beman Dawes" <bdawes_at_[hidden]> said:
> There has been a thread running with the subject "[system] Why is this 
> not header-only?" that discusses header-only versus compiled-library 
> compilation models for Boost libraries.

Yes, I have also been skimming this thread with interest, but due to
lack of time haven't been able to jump in. Thank goodness for long
weekends :)

[...]
> I'll like to challenge Boosters to think about this problem a bit more, 
> and I'd love to see someone who understands the challenges take, say, 
> Boost.System and demonstrate how it could be packaged for either 
> header-only or compiled-library use. The important goal would be to 
> abstract what to done into a general set of guidelines (and any 
> configuration support needed). In other words, we don't so much need a 
> solution for Boost.System as for any Boost library that would benefit 
> from a hybrid computation model.
> 
> Comments?

I am keen to explore a hybrid compilation model for Boost.Asio as well.
However, some analysis shows that it may be possible to make the
Boost.System library header-only while still meeting the goals of short
compile times and good software engineering practice. I'll expand on
that idea in this email and return to hybrid compilation in a later one.

Let's start by assuming that the error_code, error_category and
system_error classes in the Boost.System library are updated to match
the interfaces described in N2174 [1]. This eliminates the need for a
global vector to track error_category registration.

My reading of POSIX suggests that it is legitimate for an application to
declare a POSIX-supplied function rather than include a header file [2].
The strerror and strerror_r functions can be explicitly declared to
avoid including <string.h>.

On the other hand, Windows has an excellent track record in maintaining
binary compatibility. In my opinion, it is feasible to declare the
necessary Windows API functions and constants and thus eliminate the
dependency on <windows.h>. There is precedent within boost for this
approach [3].

We can use the properties of the extern "C" linkage specification to
keep the declarations out of the global namespace [4]. For example:

  namespace boost { namespace detail { namespace posix {
    extern "C" char* strerror(int);
  }}}

This can be supplemented with unit tests to ensure that the declarations
match those in the corresponding system header file.

That about covers it, I think. The explicit declaration approach doesn't
scale as well to Boost.Asio because it needs system-defined structures
(e.g. sockaddr_in) in addition to function declarations, but that is
where a hybrid approach may be useful.

Cheers,
Chris

---
[1] http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2174.html
[2]
http://www.opengroup.org/onlinepubs/000095399/xrat/xsh_chap02.html#tag_03_02_01
[3] boost/detail/interlocked.hpp
[4] C++2003, [dcl.link]