Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-07-03 12:21:17


----- Original Message -----
From: "Don Waugaman" <dpw_at_[hidden]>

> Would there be something wrong with combining the two approaches?
>
> #if !defined(BOOST_XXX_68C2D2A0_6FD1_11d5_8F0C_00105AC8B6E1)
> #include "boost/xxx"
> #endif
>
> Low probability of collisions with a convention at pointing to the header
> file name.

That's the idea, but it's just so that if you write two headers on the same
day they get different #include guards. Others propose putting the path to
the header in the include guard, which, when combined with mangling:

    BOOST_PYTHON_DETAIL_EXTENSION_CLASS_DWA07022001_H_

has no significant advantages over the simpler mangled name:

    EXTENSION_CLASS_DWA07022001_H_

(AFAICT).

> After a quick look at the coding standards, it seems to imply something
> of this sort (the example preprocessor symbol is RECTANGLE_DWA050499_H_)
> for the header for the class rectangle. A Boost-specific convention
> could be to have the first two underscore-separated names be the name
> of the file (uppercased, of course) - or perhaps have the file name
> end with the characters _H_ in the preprocessor symbol, then have the
> guid after that.

I think a strong convention is actually harmful, because it will encourage
users to rely on it.

All I care about is:
1. #include guards should be sufficiently unique to avoid colliding for all
practical purposes.
2. It should not take me more than about 2 seconds to come up with the
#include guard for a new header.

The guideline as written does that. Someone will have to come up with a
pretty compelling argument to get me to change it. Actually, if the group as
a whole had a strong preference for something else, and could agree on what
that was, I would consider changing it, even if the group couldn't justify
the decision. If y'all want to discuss this and come up with a consensus
counterproposal, go for it. I will sit out and wait for the outcome.

-Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk