From: Beman Dawes (beman_at_[hidden])
Date: 2000-11-07 11:18:45
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.
These names are implementation details, and not part of the public
interface. Thus if they are a bit on the ugly side that may be an
advantage because it both reduces the chance of name clashes and warns
users to avoid these names.
Boost is about to review John Maddock's static assert, which has a macro as
part of its public interface. Beyond that, I'm about to propose some test
tools, which will have two macros as part of their public interface. Thus
boost users and developers may be writing code like:
BOOST_STATIC_ASSERT( a == b );
BOOST_TEST_ASSERT( c == d );
BOOST_TEST_VERIFY( e == f );
Let's assume those names do a good job of denoting the semantics, and talk
about their lexical aspect.
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?
For example, would this be better:
static_assert_macro( a == b );
test_assert_macro( c == d );
test_verify_macro( e == f );
or this:
static_assert_macro_( a == b );
test_assert_macro_( c == d );
test_verify_macro_( e == f );
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.
--Beman