From: Daryle Walker (darylew_at_[hidden])
Date: 2001-07-20 17:43:45
on 7/19/01 12:43 PM, Vesa Karvonen at vesa.karvonen_at_[hidden] wrote:
> Proposed requirement
> Every library that has forward declarable entities such as classes, must
> contain a forward declaration header, that declares the public interface of
> the library.
I like this idea. I already add forward declarations in front of the
headers I put in Boost. I don't know if we should make it mandatory. And
nothing would stop a third-party from contributing a forward header, as long
as everyone remembers to keep it in-sync.
> A forward declaration header contains declarations of public interface
> classes, class templates, typedefs and possibly constants, and enumerations,
> but not function prototypes, or class definitions, unless those are required
> by interface declarations.
Why not function prototypes?
> A forward declaration header must not include other headers except possibly
> other forward declaration headers.
We may need <boost/config.hpp> too. Look at <boost/crc.hpp> for an example.
(The type of some template arguments is dependent on a config #define.)
> Proposed supporting guideline
> It is recommended to name forward declaration headers consistently using one
> of the following two forms depending on the organization of the library:
> A) <boost/library_name_fwd.hpp>
> For top level libraries that do not have a dedicated directory.
> B) <boost/library_name/fwd.hpp>
> For libraries that have a dedicated directory.
[TRUNCATE rationale and references & bibliography]
I think "fwd" is too short for a file (main part) name. Keeping the
"library_name_" part is extra protection from directory search screw-ups.
We have an example of this already: <boost/pool/poolfwd.hpp>.
An alternate plan would have the forward file in the main directory. For
instance, with separate utility component headers, we could have:
* utility_fwd.hpp // Forwards for rons_member.hpp, etc.
-- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk