Re: [boost] static_assert: conforming compiler preference

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

From: "John Maddock" <John_Maddock_at_[hidden]>

> >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).
>
> 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.

I hadn't thought about warnings.  Given sprurious warnings that could result
without __LINE__, then I agree it has value and doesn't hurt (so long as it
isn't broken on the compiler).

> >Also BOOST_USE_ENUM_STATIC_ASSERT, should not be
> >specific to the static_assert, but should describe the compiler feature
> >generically.
>
> 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.

I didn't realize that this was intended only to display a different error
message, in case that worked out better on a given comipler.  I thought it
was a workaround for compilers that were non-conformant WRT the typedef
method somehow.  Maybe you could clarify this a bit in the comments.  Given
the intent of the macro, I agree that the existing name is suitable.

> >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.
>
> 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.

It would be worth documenting that even given conforming compilers, using
the namespace reduces the likelihood of warnings when porting the code.
Also, it should be clear that the separate namespace only provides value
when used in a header.  IMHO, example 1 should start out by specifying the
bottom line recommended usage: namespace (not global) scope for headers and
namespace (including global) scope for non-headers.

There is one other suggestion I have thought of regarding the documentation:
Turn the examples headings into use pattern headings.  Currently, there is
no normative definition of how static assert may be used.  Can it be used in
an enum, for example?  By looking at the code and thinking, you can realize
that no, it cannot.  It would be nice if the documentation lent itself to
quickly answering these types of questions by providing a comprehensive
listing of how static assert can be used.  Really, it already does this;
reclassifying the examples as defined usages would make this clear.