From: John Maddock (John_Maddock_at_[hidden])
Date: 2000-11-14 07:33:24
>1. The current implementation violates the principle of putting making the
>mainline implementation favor conforming compilers. Ask yourself, "If
>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
Although the __LINE__ macro may not strictly be required - it does not add
any user requirements - the need to place namespace scope assertions in
their own namespace is only for broken compilers (perhaps I should make
this clearer). Compilers are also entitled to emit warnings when faced
with duplicate typedefs - in fact I would expect them to do so. IMO the
__LINE__ workaround should be the default - it just so happens that
__LINE__ is broken in VC6.
>Also BOOST_USE_ENUM_STATIC_ASSERT, should not be
>specific to the static_assert, but should describe the compiler feature
What compiler feature? We're just looking at error messages here. BTW
there are no compilers that I know of that require the use of enums rather
than typedefs - *possibly* we can remove that all together, but I wanted
people to have a chance to test the two versions just in case.
>2. I believe we should apply the same line of thought about writing
>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.
OK but there seems to be only one compiler (VC6 stangely) that is
conforming in this respect, conforming compilers may still output warnings
even if they don't choke on the code as such. IMO it's always safer to use
a separate namespace for global static asserts.
>3. Finally, there are some grammatical errors and rewording opportunities.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk