26-02-2015, 03:53 PM
Rule 8.12 : Within an enumerator list, the value of an implicitly-specified enumeration constant shall be unique
The purpose of this rule is clearly to catch two enumerated constants that are *accidentally* assigned the same value. To this end, it makes sense to flag two constants with the same value, where one is auto assigned and one is manually assigned. However, I sometimes employ a paradigm that triggers a violation of this rule where I feel it is extremely clear that the duplicate assignment is not accidental, and so it would be nice to have an exception for this in future editions of the standard. It looks like this:
The symbols LAST_GROUP_ONE and LAST_VALUE are obviously assigned the same numeric value as TYPE3 and TYPE5 respectively, without regard to what that actual numeric value is. This purpose for this is to allow writing loops to iterate over the set or sub sets of the listed types in the enum or to test whether a value is on one subset or another. Explicitly assigning one symbolic name to the other could not possibly be an accident, so I think it makes a good exception to this rule.
The purpose of this rule is clearly to catch two enumerated constants that are *accidentally* assigned the same value. To this end, it makes sense to flag two constants with the same value, where one is auto assigned and one is manually assigned. However, I sometimes employ a paradigm that triggers a violation of this rule where I feel it is extremely clear that the duplicate assignment is not accidental, and so it would be nice to have an exception for this in future editions of the standard. It looks like this:
Code:
enum {
FIRST_GROUP_ONE,
TYPE1 = FIRST_GROUP_ONE,
TYPE2,
TYPE3,
LAST_GROUP_ONE = TYPE3,
FIRST_GROUP_TWO,
TYPE4 = FIRST_GROUP_TWO,
TYPE5,
LAST_GROUP_TWO = TYPE5
}The symbols LAST_GROUP_ONE and LAST_VALUE are obviously assigned the same numeric value as TYPE3 and TYPE5 respectively, without regard to what that actual numeric value is. This purpose for this is to allow writing loops to iterate over the set or sub sets of the listed types in the enum or to test whether a value is on one subset or another. Explicitly assigning one symbolic name to the other could not possibly be an accident, so I think it makes a good exception to this rule.