3.3.6 - Class scope: reordering member declarations

[Steven T. Hatton]

If find the following excerpt from the Standard a bit confusing:
<quote>
3.3.6 - Class scope [basic.scope.class]

-1- The following rules describe the scope of names declared in classes.

1) The potential scope of a name declared in a class consists not only of
the declarative region following the name's declarator, but also of all
function bodies, default arguments, and constructor ctor-initializers in
that class (including such things in nested classes).

2) A name N used in a class S shall refer to the same declaration in its
context and when re-evaluated in the completed scope of S. No diagnostic is
required for a violation of this rule.

3) If reordering member declarations in a class yields an alternate valid
program under (1) and (2), the program is ill-formed, no diagnostic is
required.
</quote>

If I change the order of initialization of class member variables, that can
certainly change the behavior of a program. I believe both of the
following are valid class definitions. They will, however, result in
different initial states when constructed with the same actual parameter.

struct S{ int a, b; S(int bb):a(b),b(bb){} };
struct T{ int b, a; T(int bb):a(b),b(bb){} };

That seems to contradict 3) above. Aren't two programs that behave
differently "alternate valid programs"? I'm confident that I am failing to
understand something here, but I don't see what it might be. Any ideas?

 

[Greg]

If find the following excerpt from the Standard a bit confusing:
<quote>
3.3.6 - Class scope [basic.scope.class]

-1- The following rules describe the scope of names declared in classes.

1) The potential scope of a name declared in a class consists not only of
the declarative region following the name's declarator, but also of all
function bodies, default arguments, and constructor ctor-initializers in
that class (including such things in nested classes).

2) A name N used in a class S shall refer to the same declaration in its
context and when re-evaluated in the completed scope of S. No diagnostic is
required for a violation of this rule.

3) If reordering member declarations in a class yields an alternate valid
program under (1) and (2), the program is ill-formed, no diagnostic is
required.
</quote>

If I change the order of initialization of class member variables, that can
certainly change the behavior of a program. I believe both of the
following are valid class definitions. They will, however, result in
different initial states when constructed with the same actual parameter.

struct S{ int a, b; S(int bb):a(b),b(bb){} };
struct T{ int b, a; T(int bb):a(b),b(bb){} };

That seems to contradict 3) above. Aren't two programs that behave
differently "alternate valid programs"? I'm confident that I am failing to
understand something here, but I don't see what it might be. Any ideas?

There is only one class declaration which does not change - so there is
only one program being considered. The "reordering" of the class
declaration is strictly conceptual. The compiler evaluates the class
declaration from two different angles - and if the interpretation of
the declaration changes as a consequence - the program is ill-formed
(though the compiler is not obliged to tell you that).

Greg

 

[Alf P. Steinbach]

* Steven T. Hatton:

If find the following excerpt from the Standard a bit confusing:
<quote>
3.3.6 - Class scope [basic.scope.class]

-1- The following rules describe the scope of names declared in classes.

1) The potential scope of a name declared in a class consists not only of
the declarative region following the name's declarator, but also of all
function bodies, default arguments, and constructor ctor-initializers in
that class (including such things in nested classes).

2) A name N used in a class S shall refer to the same declaration in its
context and when re-evaluated in the completed scope of S. No diagnostic is
required for a violation of this rule.

3) If reordering member declarations in a class yields an alternate valid
program under (1) and (2), the program is ill-formed, no diagnostic is
required.
</quote>

If I change the order of initialization of class member variables, that can
certainly change the behavior of a program. I believe both of the
following are valid class definitions. They will, however, result in
different initial states when constructed with the same actual parameter.

struct S{ int a, b; S(int bb):a(b),b(bb){} };
struct T{ int b, a; T(int bb):a(b),b(bb){} };

That seems to contradict 3) above. Aren't two programs that behave
differently "alternate valid programs"? I'm confident that I am failing to
understand something here, but I don't see what it might be. Any ideas?

S exhibits Undefined Behavior.

But I'm not sure what the text you quoted really means.

*Checking out the standard, looking for further info*...

Well, would you look at that, there's an example following para 5.

Now at least para 2 is clear (it refers to multiple declarations of the
same name, where which one is referred to could be changed by reordering
except that para 2 forbids it), but I'm still not sure about 3.

 

[Greg]

*Checking out the standard, looking for further info*...

Well, would you look at that, there's an example following para 5.

Now at least para 2 is clear (it refers to multiple declarations of the
same name, where which one is referred to could be changed by reordering
except that para 2 forbids it), but I'm still not sure about 3.

There was a thread on comp.c++.moderated about "reordering" class
declarations. See http://tinyurl.com/yjdq4p and follow-ups posts.

Greg

 

[Steven T. Hatton]

* Steven T. Hatton:

If find the following excerpt from the Standard a bit confusing:
<quote>
3.3.6 - Class scope [basic.scope.class]

-1- The following rules describe the scope of names declared in classes.

1) The potential scope of a name declared in a class consists not only of
the declarative region following the name's declarator, but also of all
function bodies, default arguments, and constructor ctor-initializers in
that class (including such things in nested classes).

2) A name N used in a class S shall refer to the same declaration in its
context and when re-evaluated in the completed scope of S. No diagnostic
is required for a violation of this rule.

3) If reordering member declarations in a class yields an alternate valid
program under (1) and (2), the program is ill-formed, no diagnostic is
required.
</quote>

If I change the order of initialization of class member variables, that
can
certainly change the behavior of a program. I believe both of the
following are valid class definitions. They will, however, result in
different initial states when constructed with the same actual parameter.

struct S{ int a, b; S(int bb):a(b),b(bb){} };
struct T{ int b, a; T(int bb):a(b),b(bb){} };

That seems to contradict 3) above. Aren't two programs that behave
differently "alternate valid programs"? I'm confident that I am failing
to
understand something here, but I don't see what it might be. Any ideas?

S exhibits Undefined Behavior.

But I'm not sure what the text you quoted really means.

*Checking out the standard, looking for further info*...

Well, would you look at that, there's an example following para 5.

Now at least para 2 is clear (it refers to multiple declarations of the
same name, where which one is referred to could be changed by reordering
except that para 2 forbids it), but I'm still not sure about 3.

I believe I finally figured it out. It hinges on what is meant by "under
(1) and (2)". It just means "we are only talking about reordering as it
involves these rules".

As for S exhibiting undefined behavior, I thought it would be unspecified
behavior. That is, it is legal to use an uninitialized int, there's just
no guarantee as to its value.

 

[David Harmon]

On 6 Dec 2006 04:22:11 -0800 in comp.lang.c++, "Greg"

There was a thread on comp.c++.moderated about "reordering" class
declarations. See http://tinyurl.com/yjdq4p and follow-ups posts.

Never believe anything that has to hide behind tinyurl.com.

A legitimate URL for the same article is
http://groups.google.com/groups?threadm=1156692730.687050.132240@h48g2000cwc.googlegroups.com