Member with same name as type

[Ian Collins]

I encountered this example in a C header, is the following legal?

typedef long ios;

struct X
{
ios ios;
};

It complies with comeau online and Sun CC, but g++ reports

/tmp/c.cc:6: error: declaration of 'ios X::ios'
/tmp/c.cc:2: error: changes meaning of 'ios' from 'typedef long int ios'

 

[Alf P. Steinbach]

* Ian Collins:

I encountered this example in a C header, is the following legal?

typedef long ios;

struct X
{
ios ios;
};

It complies with comeau online and Sun CC, but g++ reports

/tmp/c.cc:6: error: declaration of 'ios X::ios'
/tmp/c.cc:2: error: changes meaning of 'ios' from 'typedef long int ios'

As I recall it's non-conforming.

I leave it to you to look it up in the standard, but anyway the practical
conclusion is to never write code like that.

Microsoft developers sometimes do (e.g. it occurs in the GDI+ header files), it
marks them as braindead zombies.


Cheers & hth.,

- Alf

 

[Ian Collins]

* Ian Collins:

As I recall it's non-conforming.

I leave it to you to look it up in the standard, but anyway the
practical conclusion is to never write code like that.

We didn't write the code, it's 3rd part C code!

 

[Pascal J. Bourguignon]

We didn't write the code, it's 3rd part C code!

Notice that modifying the name of a field won't impact the 3rd party
compiled libraries, so you can patch your copy of the headers without
any difficulty.

 

[James Kanze]

I encountered this example in a C header, is the following legal?

typedef long ios;

struct X
{
ios ios;
};

It complies with comeau online and Sun CC, but g++ reports

/tmp/c.cc:6: error: declaration of 'ios X::ios'
/tmp/c.cc:2: error: changes meaning of 'ios' from 'typedef long int ios'

It's undefined behavior. §3.3.6: "The followong rules describe
the scope of names declared in 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."

The first ios refers to the typedef in its context, but will
bind to the member variable when re-evaluated in the complete
scope of X.

 

[James Kanze]

Notice that modifying the name of a field won't impact the 3rd
party compiled libraries, so you can patch your copy of the
headers without any difficulty.

Alternatively, replacing the first ios in the struct with long
won't cause any problems either. Formally, either change is
undefined behavior in C++. In C, changing the name of the type
without changing the actual type is legal, and required to work
by the C standard; changing the name of the member is undefined
behavior. Practically, of course, either change will work
without problems in both languages (at least with current
compilers).

 

[Ian Collins]

It's undefined behavior.

I though so, thanks James.

§3.3.6: "The followong rules describe
the scope of names declared in 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."

That's odd wording, I wonder why it's stated that no diagnostic is required?

The first ios refers to the typedef in its context, but will
bind to the member variable when re-evaluated in the complete
scope of X.

Another corner case where C declarations don't quite work in C++.