This surprised me...

[Graham]

Someone at work discovered this:

enum Whatever
{
	One, Two
};

Whatever Whatever;

int main()
{
	Whatever = Two;
}

Comeau is quite happy with it.

I presume it comes about because of some complicated interaction of the various name lookup rules, but it strikes me as a potential cause for sleepless nights trying to trace a bug...

[PadexArt]

MSVC 6.0 has no problems either with this code.

[panayotisk]

VC++ 7.0 compiles it also.
I do not have the C++ standard handy. Allowing this can be confusing I guess.

[exterminator]

Even this is allowed by Comeau as well as VC++ 6.0

#include <iostream>
class Whatever{
	public:
		int i;
};
int main()
{
	Whatever Whatever;
	Whatever.i = 20;
	std::cout << Whatever.i;
	return 0;
}

It allows the name of the class to be the name of the Object of that class. Is this what you are pointing to? It can be a misleading though I am unable to find an instance, yet.

Tweaking it a little bit more, I tried this:

#include <iostream>
class Whatever{
	public:
		int i;
};
class AnotherWhatever{
	public:
		static int i;
};
static int i = 10;
int main()
{
	Whatever AnotherWhatever;
	AnotherWhatever.i = 20;
	std::cout << AnotherWhatever.i;
	return 0;
}

It considers AnotherWhatever as the object and it does not allow me to get to the class with the static member no matter what I do. So, I guess this wouldnt result in ambiguities from a coder's viewpoint - provided this is what you are referring to in the enum example.

[ruobrab]

This also works for structs and classes.

I dont think it is illegal C code, but it should be with a severe penalty!

I found a quirk with this using MSVC 6:

enum Whatever
{
One, Two
};

void printwhatever (Whatever Whatever){
if(Whatever == Two)
printf("two");
}

Whatever Whatever;

int main(int argc, char* argv[])
{
Whatever = Two;
printwhatever(Two);
return 0;
}

this works, but if the global Whatever is declared before the function it doesnt, i suppose this is a compiler bug? As iam asuming that it doent break the rules of C.

[Vanaj]

You can give an enumeration a type name and use the type name to define variables. For example:

enum card_suit
{
    CLUBS,
    DIAMONDS,
    HEARTS,
    SPADES
} card1;

enum card_suit card2, pack[52];

Here, card1 and card2 are variables of type enum card_suit, and pack is an array of 52 elements of type enum card_suit.

As variables of this type, they CAN be assigned only the constants CLUBS, DIAMONDS, HEARTS, or SPADES. NO other assigment is legal:

card1 = CLUBS;    /* legal */
pack[5] = card2 = DIAMONDS;   /* legal */
card2 = 100;   /* ERROR  */

Only a few operations are possible with variables of an enumerated type. They can be assigned one of the constants in the enum series, they can be assigned values from other expressions of the same type, and they can be compared to other expressions of the same type.

[NMTop40]

It becomes a problem when an ambiguity arises.

class X
{
public:
  explicit X ( Whatever ) ;
};

int func()
{
   Whatever Whatever;

   X anX( Whatever ); // ambiguous
};

[SuperKoko]

Someone at work discovered this:

enum Whatever
{
	One, Two
};

Whatever Whatever;

int main()
{
	Whatever = Two;
}

Comeau is quite happy with it.

I presume it comes about because of some complicated interaction of the various name lookup rules, but it strikes me as a potential cause for sleepless nights trying to trace a bug...

There are limitations to name redefinition:

-3- Change: In C++, a typedef name may not be redefined in a class declaration after being used in the declaration
Example:

typedef int I;
struct S {
I i;
int I; // valid C, invalid C++
};


Rationale: When classes become complicated, allowing such a redefinition after the type has been used can create confusion for C++ programmers as to what the meaning of 'I' really is.
Effect on original feature: Deletion of semantically well-defined feature.
Difficulty of converting: Semantic transformation. Either the type or the struct member has to be renamed.
How widely used: Seldom.

However, name redefinition is useful for local variables, because local variables may be numerous and have insignifiant names.
If, there was an error when a type was reused as local variable, it would be problematic when adding new types, and seeing that they conflict with some local variables of already-well-written functions.
In my point of view, the body of a function must be opaque for the remaining of the code, and must not conflict.

But, i think that it is bad to redefine a name, for a global variable, because the global variable is not opaque.

[Vedam Shashank]

I just hope people dont start coding like that. Even if they do, i pray that i dont come across such projects.

I can imagine myself trying to trace some part of program..., come across 'Whatever'.., look at its definition.., and find that - it is also 'Whatever'. I wll probably be searching for its definition scratching my head forever.

[SuperKoko]

Sure, it is bad to use this feature, but it is useful that this feature exists.
In the same order of idea, a local variable or a class member may have the same name that a global variable.

[RoboTact]

And it's sometimes OK to use the same name for field and access method (which isn't necessary just returning it). With IDE showing fields using color different from that for other variables, underscores or such seem wrong.