Movatterモバイル変換

1. According to11.4.9.3 [class.static.data] paragraph 4, a static const integral or const enumeration data member initializedwith an integral constant expression "can appear in integral constant expressionswithin its scope" [emphasis mine]. This means that the followingis not permitted:

       struct S {        static const int c = 5;    };    int a[S::c];    // error: S::c not in scope

   Is this restriction intentional? If so, what was the rationale for therestriction?

   Bjarne Stroustrup: I think that once you have saidS::,c is in scope so that

       int a[S::c];

   is ok.

   Mike Miller: I'd like to think that's what it meant, but Idon't believe that's what it said. According to6.4 [basic.scope] paragraph 1, the scope ofa name is the region "in which that name may be used as an unqualifiedname." You can, indeed, use a qualified name to refer to a name thatis not in scope, but that only goes to reinforce my point that"S::c" is not in scope at the point where the expressioncontaining it is used. I think the phrase "within its scope" is atbest misleading and should be removed. (Unless there's a reason I'mmissing for restricting the use of static member constants to theirscope.)

2. According to 7.7 [expr.const]paragraph1, integral constant expressions can "involve...const variables or staticdata members of integral or enumeration types initialized with constantexpressions." However, in 7.7 [expr.const] paragraph 3, arithmetic constant expressions cannot include them. Thisseems a rather gratuitous distinction and one likely to bite programmerstrained always to use const variables instead of preprocessor definitions.Again, is there a rationale for the difference?

   As far as I can tell from 7.7 [expr.const] paragraph 2, "arithmetic constant expressions" (as distinct from "integralconstant expressions") are used only in static initializers to distinguishbetween static and dynamic initialization. They include floating pointtypes and exclude non-type template parameters, as well as the const variablesand static data members.

3. There is a minor error in 7.7 [expr.const] paragraph 2. The first sentence says, "Other expressions are consideredconstant expressions only for the purpose of non-local static object initialization."However, 8.10 [stmt.dcl] paragraph 4appearsto rely on the same definition dealing with the initialization of localstatic objects. I think that the words "non-local" should be dropped anda cross reference to 8.10 [stmt.dcl]added.

4. 7.7 [expr.const] paragraph 4says, "An expressionthat designates the address of a member or base class of a non-POD classobject (clause 9) is not an address constant expression (11.9.5 [class.cdtor])."

   I'm guessing that should be "non-static member," like the similarprohibition in 11.9.5 [class.cdtor] regardingout-of-lifetime access to members of non-POD class objects.

Proposed resolutions (10/00):

1. Remove the phrase "within its scope" in11.4.9.3 [class.static.data] paragraph 4.

2. Replace 7.7 [expr.const] paragraph 3 with the following:

   Anarithmetic constant expression shall satisfy therequirements for an integral constant expression, except that

   • floating literals need not be cast to integral or enumerationtype, and
   • conversions to floating point types are permitted.

3. This is not a defect; no change is required. The suggestedwording would be more accurate, but since the effect on localinitialization is unobservable the current wording is adequate.

4. Change the referenced sentence in 7.7 [expr.const] paragraph 4to "An expression that designates the address of asubobject of a non-POD class object is not an address constantexpression."