On Fri, 06 Apr 2007 10:57:06 -0400, "Beman Dawes" <bdawes@acm.org> 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... [3] boost/detail/interlocked.hpp [4] C++2003, [dcl.link]