static_assert: conforming compiler preference

From: Ed Brey (brey_at_[hidden])
Date: 2000-11-13 09:47:56

Comments on static assert, which I believe should be accepted into boost:

1. The current implementation violates the principle of putting making the
mainline implementation favor conforming compilers.  Ask yourself, "If every
compiler were perfect, how would we implement it."  The answer is that we
would not use the __LINE__ macro, since it is not necessary, and its usage
puts an constraint on the user (need to use unique namespace when using
within header).

To solve this problem we should have a config flag that indicates if the
compiler is broken and doesn't ignore duplicate typedefs.  We use that guide
our implementation.  Also BOOST_USE_ENUM_STATIC_ASSERT, should not be
specific to the static_assert, but should describe the compiler feature
generically.  So here's how I propose it would look:

#ifndef BOOST_DEFERRED_TEMPLATE_EVALUATION
#ifndef BOOST_NO_DUPLICATE_TYPEDEFS

#define BOOST_STATIC_ASSERT(B) typedef \
::boost::ct_assert_test<sizeof(::boost::STATIC_ASSERTION_FAILURE<(B)>)> \
boost_static_assert_typedef_

#else // Compiler can't handle duplicate typedefs:

#define BOOST_STATIC_ASSERT(B) typedef \
::boost::ct_assert_test<sizeof(::boost::STATIC_ASSERTION_FAILURE<(B)>)> \
BOOST_JOIN(boost_static_assert_typedef_, __LINE__)

#else // Compiler evaluated templates late, so use enum:

#define BOOST_STATIC_ASSERT( B ) enum \
{ BOOST_JOIN(boost_static_assert_enum_, __LINE__) = \
sizeof(::boost::STATIC_ASSERTION_FAILURE<(B)>) }

#endif

(Line continuation added to prevent arbitrary line wrapping by my mail
client.  It is not an endorsement of any style.  Choice of template name
used within sizeof is an underhanded vote for my naming preference that I
shouldn't really be addressing in this thread. :->)

I'm not sure what the best way to set up BOOST_NO_DUPLICATE_TYPEDEFS is.  It
depends on how many compilers are non-conformant in this regard.  If, by
some twist of irony, Microsoft is nearly the only one to get this right,
config.hpp could define the macro and undef it for MSVC; otherwise, if many
vendors handle this, then we can just turn it on for non-conforming
compilers at we normally do with such macros.

2. I believe we should apply the same line of thought about writing foremost
to conforming compilers to the documentation as well.  Example 1 should
indicate that static assert can be used at global scope or any other
namespace scope, and give an example of each.  It should have a link to a
portability section where there would be listed the workaround needed for
putting a header with a static assert through a non-conforming compiler.

3. Finally, there are some grammatical errors and rewording opportunities.
I've documented them in the for "old text -> new text".

the assert macro, this is sometime  ->
the assert macro; this is sometime

When used in a template, then the static assertion ->
When used in a template, the static assertion

aims of BOOST_STATIC_ASSERT is that it should generate ->
aims of BOOST_STATIC_ASSERT is to generate

error messages, these immediately
error messages. These immediately

compiler to compiler, but you should see ->
compiler to compiler, you should see

The key feature here is that sizeof(COMPILE_TIME_ASSERTION_FAILURE<0>) is
undefined, and produces reasonably consistent error messages across a wide
variety of compilers ->
The key feature here is the error message triggered by the undefined
sizeof(COMPILE_TIME_ASSERTION_FAILURE<0>) tends to be consistent and across
a wide variety of compilers.

a wide variety of compilers, the rest of the machinery ->
a wide variety of compilers. The rest of the machinery

here is somewhat ugly, however boost ->
here is somewhat ugly; however, boost