3.3.6 - Class scope: reordering member declarations

  • Thread starter Steven T. Hatton
  • Start date
S

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?
 
G

Greg

Steven said:
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
 
A

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.
 
G

Greg

Alf said:
*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
 
S

Steven T. Hatton

Alf said:
* 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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top