By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
426,083 Members | 1,608 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 426,083 IT Pros & Developers. It's quick & easy.

3.3.6 - Class scope: reordering member declarations

P: n/a
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?
--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/
Dec 6 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/a

Steven T. Hatton wrote:
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

Dec 6 '06 #2

P: n/a
* 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.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Dec 6 '06 #3

P: n/a

Alf P. Steinbach wrote:
*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

Dec 6 '06 #4

P: n/a
Alf P. Steinbach wrote:
* 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.
--
NOUN:1. Money or property bequeathed to another by will. 2. Something handed
down from an ancestor or a predecessor or from the past: a legacy of
religious freedom. ETYMOLOGY: MidE legacie, office of a deputy, from OF,
from ML legatia, from L legare, to depute, bequeath. www.bartleby.com/61/
Dec 6 '06 #5

P: n/a
On 6 Dec 2006 04:22:11 -0800 in comp.lang.c++, "Greg"
<gr****@pacbell.netwrote,
>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/gr*********...oglegroups.com
Dec 6 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.