From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2000-11-12 12:47:59
Beman Dawes wrote:
>
> In the past we have used a number of macro names, always prefixed by
> BOOST_.
>
> Examples are multiple inclusion guards like BOOST_CONFIG_HPP or
> configuration artifacts like BOOST_NO_MEMBER_TEMPLATES.
> BOOST_STATIC_ASSERT( a == b );
Thus, we seem to have three classes of macros now:
- Internal include guards, (_HPP suffix)
- Internal configuration (mostly non-function-like)
- Public (mostly function-like) macros
> My question then is, "What should be the form of boost public interface
> macro names?"
> My worry is that the all uppercase, prefixed by BOOST_ rule produces names
> ugly enough that programmers will shy away from using them. Is there
> another scheme that is less ugly, but still unlikely to produce name
> conflicts?
I do not think so. Macro names are global, so we have to prefix
some kind of namespace identifier to reserve a "local" namespace.
I prefer the prefix BOOST_ to any abbreviation such as BST_.
> Maybe I'm the only one that worries about public interface macro names, but
> I'd like to someone else can come up with a better scheme before we commit
> ourselves to names that are likely to be around for many years.
I think BOOST_STATIC_ASSERT is as nice as we can get with our current
nicely non-imperialist put-everything-in-a-namespace approach. C++ is
a bit more verbose in general anyway, so users should not be alienated by
a slightly more lengthy macro name. Oh, and I want to have all macros
ALL_UPPERCASE.
However, we may want to reconsider our internal configuration macro names,
for example prefix them with BOOST_CONFIG_ or so, to make sure we can always
choose the most obvious name for public macros.
Jens Maurer