|
Boost : |
Subject: Re: [boost] [Review] Type Traits Introspection library by Edward Diener starts tomorrow Friday 1
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-07-02 12:19:47
On 7/2/2011 11:41 AM, John Bytheway wrote:
> On 02/07/11 13:57, Edward Diener wrote:
>> On 7/2/2011 4:44 AM, John Maddock wrote:
>>>>> I mean things like
>>>>>
>>>>> struct A
>>>>> {
>>>>> static const int value = 42;
>>>>> };
>>>>
>>>> That works correctly in the library for gcc and VC++. Evidently the
>>>> code that tests, which uses an expression of&A::value, is accepted by
>>>> those compilers. Is it illegal to take the address of a static const
>>>> data member in C++ ?
>>>
>>> No, but you *may* need an out-of-line definition for the member "value"
>>> if the compiler considers the address to be "used": my guess is you're
>>> only using it within the context of another metafunction, so probably
>>> this should be OK.... probably ;)
>>
>> Is there a relevant section in the C++ standard about this which you can
>> cite offhand ?
>
> Don't have a copy of the current standard, but I can quote C++0x (N3290)
> [class.static.data] (9.4.2) p3:
>
> "The member shall still be defined in a namespace scope if it is
> odr-used (3.2) in the program and the namespace scope definition shall
> not contain an initializer."
>
> The implication being that no namespace-scope definition is required
> when it is not odr-used.
>
>> In my quick test of this I did not specify an out-of-line definition but
>> then again I am not "using" the const value in any other way then to
>> test against it.
>
> The definition of odr-used ([basic.def.odr], 3.2) is quite long, but
> you're fine if it's an "unevaluated operand". In particular, see [expr]
> (5) p7:
>
> "In some contexts, unevaluated operands appear (5.2.8, 5.3.3, 5.3.7,
> 7.1.6.2). An unevaluated operand is not evaluated."
>
> These four references are typeid, sizeof, noexcept, and decltype. Is
> your use inside such an expression? I was guessing it would be in sizeof().
Yes it is sizeof().
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk