From: Christopher Currie (christopher_at_[hidden])
Date: 2003-05-07 11:13:32
David Abrahams wrote:
> Aleksey Gurtovoy <agurtovoy_at_[hidden]> writes:
>>David Abrahams wrote:
>>>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. If I'm mistaken about that, then I'd be
> inclined to agree with you.
While in theory I agree with Aleksey, I tried David's suggestion of
inhibiting in-class static constant initialization. This single change
eliminatated all but one of the remaining problems I've had compiling
the tests for type_traits (there's still an assertion happening with
type_with_alignment_test, I'll be looking into that next).
While this hides some gross inadequecies of the Sun compiler, I'm all in
favor of getting Boost to compile reliably for users of this platform.
Can someone make this change to the Sun config? Then the patch to
alignment_of is unnecessary.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk