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/