From: David Abrahams (dave_at_[hidden])
Date: 2003-05-07 06:48:27
Aleksey Gurtovoy <agurtovoy_at_[hidden]> writes:
> David Abrahams wrote:
>> Aleksey Gurtovoy <agurtovoy_at_[hidden]> writes:
>> > David Abrahams wrote:
>> >> > Looks good. I've applied it.
>> >> Maybe we should be treating Sun in the config as though it doesn't
>> >> support in-class static constant initialization (so
>> >> BOOST_STATIC_CONSTANT generates an enum)? It seems like trying to
>> >> track down all these cases piecemeal is going to be a
>> losing battle.
>> > But then Sun is right to complain there, isn't it? It's true that
>> > there are a lot of places where we are using BOOST_STATIC_CONSTANT
>> > without the corresponding and appropriately guarded definition, but
>> > if we adopt the strategy you suggest, in the end, as more and more
>> > compilers will enforce the rule, we will end up with enums
>> > everywhere; which kind of defeats the purpose of the macro - if I
>> > thought the enums are the way to go, I would never use
>> > BOOST_STATIC_CONSTANT in the first place.
>> I was under the impression that a DR had been approved which clarifies
>> the point so that if the address of the constant is never needed, no
>> definition is needed either.
> Are we talking about
> 'Cause while the stated intent of the issue is indeed formulated in these
> terms, the resolution itself is anywhere but close to it:
> "An expression is potentially evaluated unless it appears where an
> integral constant expression is required (see 5.19 expr.const ), is the
> operand of the sizeof operator (5.3.3 expr.sizeof ), or is the operand
> of the typeid operator and the expression does not designate an lvalue
> of polymorphic class type (5.2.8 expr.typeid )."
> For a library writer, it pretty much means that if a static integral
> constant member is publicly exposed, it needs to have a definition.
> The library writer _herself_ needs it for the tests, if she wants to
> check the value at runtime.
I see. That's quite disappointing, I must say... though I don't know
how to formulate the language better at this point.
>> If I'm mistaken about that, then I'd be inclined to agree with you.
> Well, having formulated the above, I just realized that the case is
> question doesn't in fact fall into that category. 'alignment_of_impl'
> is an implementation helper which 'value' member is never used, and,
> more importantly, cannot potentially be used anywhere but in the
> context where an integral constant expression is required.
> So, if Sun wants a definition for it, it's definitely a non-conforming
> behavior, and should be either guarded with a BOOST_WORKAROUND #ifdef,
> or indeed by defining BOOST_NO_INCLASS_MEMBER_INITIALIZATION. The
> latter would definitely make our life easier, if it works, and is no
> worse for the vendor's testing, if they are to pursue the conformance -
> in that case they are supposed to replace the config anyway.
Yep, I guess so.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk