Reordering class member declarations

Reordering class member declarations

Post by litb » Fri, 05 Jun 2009 01:52:17


I was wondering, does the Standard really say that the following is
ill-formed with no diagnostic required?

typedef int type;
struct X {
typedef int type;
type member;
};

Reading 3.3.6[basic.scope.class]/1.2 (c++03), i find

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

By that text, the following must be invalid too with no diagnostic
required?

struct X {
// <- re-evaluation here does not look-up to the same declaration
anymore
typedef int type;
type member;
};

I don't think that the text wants to forbid this, but that seems what
the text says is ill-formed. Can someone clear things up please?
Thanks.

--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.yqcomputer.com/ ]
 
 
 

Reordering class member declarations

Post by Richard Co » Sat, 06 Jun 2009 06:27:06


I would read this as implying that the name 'type' is first *used* for
the declaration of member. So the above is well formed, as the name
found when 'member' is declared and at the closing brace of the class
will both match the same typedef declaration.

I think this wording is only intended to catch the following example:

typedef int type;
struct X {
type member;
typedef int type;
};

Here, the member declaration uses the namespace declaration for
'type', however, if we looked up 'type' at the closing brace of the
class definition we'd find 'type' the member typedef.

In this case, it won't make any difference (both typedefs are int) but
if one of them was a different type, then it is significant.


Regards,

Richard




[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.yqcomputer.com/ ]

 
 
 

Reordering class member declarations

Post by wasti.red » Sat, 06 Jun 2009 06:27:25


No, you misunderstand. The meaning must be the same when all names in
the class are known. So this is what is ill-formed, NDR:

typedef int type;
struct S {
type member;
typedef float type;
};

The text doesn't mean "the declaration must mean the same thing no
matter where in the class declaration it appears". It says, "the
declaration must mean the same thing after parsing the remainder of
the class declaration".
The intent here is that class declarations should mean the same no
matter the order of its declarations, but reality is different -
parsers still do single-pass top-down parsing. So the standard puts
the burden of making sure that the code is unambiguous on the
programmer: ill-formed, but no diagnostic required from the compiler.

Sebastian
 
 
 

Reordering class member declarations

Post by Greg Herli » Sat, 06 Jun 2009 06:27:36


No, according to the C++ Standard the declaration of "X" above is well-
formed.


The two "type" typedef declarations are the same (both declare "type"
as a typedef for int). So whether looked up in its context or in the
full scope of X, "type" refers to the same ("same" - as in
"identical") typedef declaration in each case.

Therefore, the definition of "X" is not ill-formed.

Greg
 
 
 

Reordering class member declarations

Post by James Kanz » Sat, 06 Jun 2009 06:27:55


How does that apply here? I see no symbol which will bind
differently when evaluated in context and when evaluated in the
completed scope of the class.



But what symbol would be re-evaluated here? There are no
symbols which appear here.



What is ill-formed about it?


I'm afraid I don't see what there is to clear up. It's
unfortunate that the re-evaluation can result in undefined
behavior; it would be much better to define one single point of
lookup in each case. But in practice, the issue doesn't seem to
occur often enough to worry about.