[boost] Re: [type-traits] Patch to alignment_of.hpp for Sun c ompiler

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
> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#48?
> '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