Boost logo

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

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

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


Want to block unwanted pop-ups? Download the free MSN Toolbar now!

Boost list run by bdawes at, gregod at, cpdaniel at, john at