Why can't I assign an invalid enum element, but can I compare it with a wrong enum element?

Question

With the following C ++ definitions:

enum EnumA { EA_Element = 1 }; enum EnumB { EB_Element = 10 }; 

The following code will not compile and it makes sense:

 EnumA variable; variable = EB_Element; // won't compile 

but the following code compiles:

 EnumA variable = EA_Element; if( variable == EB_Element ) { //will compile } 

although this may not make any sense - different enumerations are compared, and such code is probably erroneous.

Why are these seemingly identical situations handled differently in C ++?

Answer 1

It will be compiled because "by default, enumerations are converted to integers for arithmetic operations." (In: C ++ programming language)

Answer 2

This argument is correct, as I have seen that any type of enum can be compared to any type of enum . This is because, for comparison purposes, enum variables and values must be converted to an integral type (e.g. int ). A specific compiler raise a warning .

Such an argument may have a value for comparison between unsigned int , int , size_t , etc., but it may be all limited by a compiler warning for the same reason.

However, this problem is addressed in C ++ 0x using the enum class (they did not modify the existing enum behavior to ensure compatibility).

Answer 3

Not that this is not possible, just that your compiler considers them to be two different data types when they are integers. Thus, a simple type of solution can solve the problem.

 EnumA variable; variable = (EnumA)EB_Element; 

Answer 4

Welcome to C ++!

for something even funny try this:

 #include <string> int main(int argc, const char *argv[]) { std::string s; s = 3.141592654; return 0; } 

why does it compile? The reason is that the rules of the language speak of this.

In this funny case, the “official” explanation of why this example compiles is that it was correct to allow std::string::operator+=(char) (IMO ok and logically from a pragmatic point of view) and therefore also the purpose from char (IMO illogical non-sequitur). But the characters are ints (illogical, but C-legacy), and doubles can be implicitly converted to ints (illogical, but C-legacy). Therefore, in C ++, it is illogical (but legal) to assign a double line.

I don’t feel bad if you don’t know, most of the C ++ programmers that I showed were puzzled by why such stupidity compiles and thinks about other semantics or compiler errors.

In the case of your question, the reason is that the enums in some contexts are similar to ints (probably due to the legacy in the use cases), but not like ints in some other context. This is absurd, but it is what complies with the standard.

If it seems uncomfortable with this, apparently, lack of logic, remember that C ++ is mainly the result of a long history and even a committee (!), So logic really has nothing to do with it. It also implies that you cannot use logic to avoid learning from C ++: no matter how smart you are, you can not guess about the historical accidents and political decisions of the committee.

The high complexity of C ++, the lack of logic in many places, and the presence of undefined behavior daemons instead of runtime error angels are also what IMO basically excludes from learning C ++ by experimentation.

Choose a good book (or several) and read it (them) on the cover ... unfortunately, there is no other way. My suggestions: "C ++ Programming Language" (Stroustrup), "Effective C ++" and "More Effective C ++" (Meyers), "C ++ Frequently Asked Questions" (Cline / Lomow / Girou).

C ++ is a pretty powerful and enjoyable weapon that you can use, but get close to it from the wrong side and it could be the worst of your nightmares. Assuming you can understand this, just using logic is the wrong approach (and not because your logic is weak, but because C ++ is not just logic).