RE: [boost] Building Libraries in Boost

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-07-27 16:59:50

Jody Hagins wrote:
>Most of boost is implemented in header files (as most is based on
>templates).  However, what are the guidelines for splitting code into
>compilable units?

As far as I know, anything sensible.

>For example, if a library is not a template library, should the author
>strive to implement it entirely in headers as inline functions, or
>should it be implemented as part inline functions and part a compiled
>library?

If the code is non-template and is non-trivial, it should really be a part 
of a compiled library. For trivial functions (e.g. returning data 
information), these should be inlined.

Boost uses the Boost.Build system to compile the libraries (see the 
installation docs for information on how to setup and configure either V1 or 
V2). You will need to create a Jamfile that describes the library so that it 
can be built (this will normally be in libs/<library>/build), with the 
source in libs/<library>/src.

I suggest that you take a look at the existing libraries that have built 
components: Boost.DateTime; Boost.RegEx; Boost.Signals; Boost.Graph; 
Boost.Thread; Boost.FileSystem and Boost.ProgramOptions. If you get stuck 
with Boost.Build you can contact the Boost.Build mailinglist.

>A fair amount of code uses the PIMPL pattern to reduce header
>complexity, reduce interface and implementation exposure, and to reduce
>compile times.  However, this requires, in large part, separate compiled
>libraries.

Whether or not to use PIMPL should be a design decision based on the library 
requirements. There are also non-class functions that may be a part of a 
library that exist in a compiled unit (see Boost.FileSystem).

Regards,
Reece

_________________________________________________________________
Want to block unwanted pop-ups? Download the free MSN Toolbar now!  
http://toolbar.msn.co.uk/