when you have:
thanksCode:enum blah {blah...} dog; dog = 1; //why are type conversions disallowed here?
when you have:
thanksCode:enum blah {blah...} dog; dog = 1; //why are type conversions disallowed here?
an enumerated data type will be cast automatically to the appropiate type, but the reverse isnt true..there is no automatic conversion from an integer type to a enumeration type
so using your example
dog = static_cast<blah>(1);
nextus, the samurai warrior
yes... but why? I mean, if c++ allows a bool to float conversion, why not an enum blah to int conversion?
Because for a given value of an enum it will fit into an int but the reverse is not true.
for me i never assume an automatic conversion will take place...i rather explicitly tell the compiler that i am casting the value into another..its just a safe caution for me....
nextus, the samurai warrior
What should the compiler do with that? Since it can't reasonably know what to do, it doesn't allow it.Code:typedef enum { red = 1, green = 2, blue = 3 } color; color c = 24;
How is it safe to cast everything? (assuming you don't refer to dynamic_cast when talking about values).Originally Posted by nextus
One could argue that this isn't true for very large values of same sized float/integer types either.
main() { int O[!0<<~-!0]; (!0<<!0)[O]+= ~0 +~(!0|!0<<!0); printf("a function calling "); }
>> How is it safe to cast everything? (assuming you don't refer to dynamic_cast when talking about values). <<
If you are explicitly making casts, then a) there are no assumptions about what is going on under the hood, and b) clearly you have thought about what you are doing, and hence, are doing it intentionally. It is still possible to do foolish things, but safer in the sense that it requires you to have thought about it.
>> One could argue that this isn't true for very large values of same sized float/integer types either. <<
You may get a very large numerical error trying to perform foolish conversions, but you will end up with a valid number (as useless as it may be). Converting from int to enum you will not necessarily end up with a valid enum value (see jlou's example).
Last edited by Zach L.; 11-23-2004 at 07:54 AM.
The word rap as it applies to music is the result of a peculiar phonological rule which has stripped the word of its initial voiceless velar stop.
nice rebuttal Zach...took the words right out of my mouth
nextus, the samurai warrior
well lets work on your example...enum does allow ranges...so if you have
Code:enum colors { red = 1, blue = 10 }; colors myColor = static_cast<colors>(5); //perfectly legal!
nextus, the samurai warrior
I wouldn't bet on that one, especially not when falling into the habit of always (as in "preemptive") using casts. :-) I see your point though.
Yes, but do you have to have? If it's an invalid enum all that happens is that your entire switch or whatever you use to test the cases fails. If you get a completely wrong number after converting an integer type to a ("more precise") floating point you might (or might not) be in worse troubles, especially since this comes completely unexpected.
Anyway, I realize there is no point in discussing what the language should allow and what not.
main() { int O[!0<<~-!0]; (!0<<!0)[O]+= ~0 +~(!0|!0<<!0); printf("a function calling "); }
Well, if you are in the habit of preemptive casting, then it is a good idea to get out of it. If you are casting too often, then there is probably a better way of doing things.
Why you would not want to cast an int to an enum really doesn't have to do with what will fit where (that is a practical consideration, though), but really what you are dealing with is a violation of an abstraction. If you want an arbitrary integer, use an int. If you want something from a set list of items that have some other inherent meaning, use an enum.
The word rap as it applies to music is the result of a peculiar phonological rule which has stripped the word of its initial voiceless velar stop.
