Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign

bitwise operation on enum types

<< < (2/2)

oBFusCATed:

--- Quote from: ollydbg on November 17, 2013, 06:49:36 am ---They don't worry about different types.
--- End quote ---
I worry because as far as I know an enumerator type must be assigned only with its values. If you do a cast to assign then it is the same as int.
you can test the size of TokenKind with sizeof. I suppose it will give you 4 bytes, because it is either int or unsigned int.

thomas:

--- Quote from: oBFusCATed on November 15, 2013, 05:46:13 pm ---
--- Quote from: thomas on November 15, 2013, 05:01:12 pm ---It is strictly legal for an enumeration value to be a value that is not part of the enumeration definition, as long as it fits the storage size.

--- End quote ---
Can you quote the standard?
--- End quote ---
I could, but I won't. That would be 15 or 20 minutes wasted on searching, which is kind of pointless.

thomas:
There you go, second last sentence of §7.2 par 8:

--- Quote ---It is possible to define an enumeration that has values not defined by any of its enumerators.
--- End quote ---

oBFusCATed:
Hm, if I understand §7.2 par 8 correctly, then you're wrong, because this paragraph explicitly forbids int to enum conversions.

Here is the example taken from the standard:

--- Code: ---enum color { red, yellow, green=20, blue };
color col=red; // ok
color c=1; // error - type mismatch, no conversion from int to color
int i=yellow; //ok, yellow converted to integral value 1

--- End code ---

thomas:
That's an implicit conversion. It's illegal, and for a good reason (because it is almost certainly a programming error).
C++11 type-safe enumerations even go one step further and also forbid implicit conversions in the other direction.

The standard also states (one or two paragraphs earlier, I think) that the values of an enumeration are all values in the range between the smallest and largest value defined. In other words, in enum{a, b=500}; any value between 0 and 500 inclusive is well-defined. I believe to remember a wording like "if representable by the underlying storage size" too, although I can't provide a reference for that out of memory.

The wording on the min/max range, if one is pedantic, doesn't include bitwise-or of any enum values (it does include bitwise-or of any but the biggest-log2 values though, or in the case of a bit-flag type of enum, any operation not including the largest value).
That's obvious, since biggest|some_other_value >= biggest. But if one is pedantic, it also doesn't say the opposite, the wording is "the values are", "not all legitimate values are".

Though it explicitly allows almost the exact case you're after, and if the "almost" bit really bothers you, you can always add a bigger value to each enumeration that is twice the value of the otherwise biggest value. Then there is no way someone could claim, even theoretically or in a contrieved case, that this isn't explicitly allowed.

Navigation

[0] Message Index

[*] Previous page