specifying enumeration size as member: good or bad

[Neil Zanella]

Hello,

I have seen code that does the following:

enum Letter { X, Y, Z, numLetters };

Is this considered good or bad code? On one hand, the code seems more
maintainable because no matter whether letters are added or removed
the value of numLetters will be correct (as long as no letter is
given a number with the equal sign which makes this untrue).

On the other hand, this forces the need for needless default
cases in switch statements since the compiler will complain
if in a switch numLetters above is not taken care of.

So, is this good or bad?

Opinions welcome,

Regards,

Neil

[Mike Wahler]

Re: specifying enumeration size as member: good or bad

"Neil Zanella" <nzanella@cs.mu n.ca> wrote in message
news:b68d2f19.0 404021410.47847 bd@posting.goog le.com...[color=blue]
> Hello,
>
> I have seen code that does the following:
>
> enum Letter { X, Y, Z, numLetters };
>
> Is this considered good or bad code? On one hand, the code seems more
> maintainable because no matter whether letters are added or removed
> the value of numLetters will be correct (as long as no letter is
> given a number with the equal sign which makes this untrue).[/color]

As long as all the values have sequential values
beginning with zero, as is the default. Some or
all of these values could be explicitly specified
if desired.[color=blue]
>
> On the other hand, this forces the need for needless default
> cases in switch statements since the compiler will complain
> if in a switch numLetters above is not taken care of.[/color]

What do you mean? It needs no 'taking care of'.
A 'switch' statement will only do what you tell
it to with particular values, and nothing with
others. What error message are you getting,
with what specific code?

enum Letter value = Y;


switch(value)
{
case X:
/* whatever */
break;
}

Note that only one value is processed by the switch.
This should not result in a compiler error.
[color=blue]
>
> So, is this good or bad?[/color]

Using 'one more' value in a list of sequential enumeration
values is sometimes used to maintain a 'count' of the
values, yes. Whether it's 'good' or 'bad' really depends
upon what you're doing.

-Mike

[Claudio Puviani]

Re: specifying enumeration size as member: good or bad

"Neil Zanella" <nzanella@cs.mu n.ca> wrote[color=blue]
> Hello,
>
> I have seen code that does the following:
>
> enum Letter { X, Y, Z, numLetters };
>
> Is this considered good or bad code?[/color]

I consider it to be bad because it breaks the cohesion of the type. The type
'letter' now represents two separate concepts: letters AND the number of
possible letters. If you had a set (in the generic sense, not the standard
container) of letters, this type indicates that the set could contain
'numLetters' as a valid member, which is completely absurd. 'numLetters'
should be a separate constant. Both the enum and the constant -- along with
various utility functions -- could be kept in a common namespace or class if
they need to be packaged together, but never in the same enum.
[color=blue]
> On one hand, the code seems more maintainable because
> no matter whether letters are added or removed the value
> of numLetters will be correct (as long as no letter is
> given a number with the equal sign which makes this untrue).[/color]

It's a lot more maintainable to change one constant if the enum is changed
than to track down errors because the enum is incorrectly designed.
[color=blue]
> On the other hand, this forces the need for needless default
> cases in switch statements since the compiler will complain
> if in a switch numLetters above is not taken care of.[/color]

At the very least.
[color=blue]
> So, is this good or bad?[/color]

Definitely bad.

Claudio Puviani

[Nick Hounsome]

Re: specifying enumeration size as member: good or bad


"Neil Zanella" <nzanella@cs.mu n.ca> wrote in message
news:b68d2f19.0 404021410.47847 bd@posting.goog le.com...[color=blue]
> Hello,
>
> I have seen code that does the following:
>
> enum Letter { X, Y, Z, numLetters };
>
> Is this considered good or bad code? On one hand, the code seems more
> maintainable because no matter whether letters are added or removed
> the value of numLetters will be correct (as long as no letter is
> given a number with the equal sign which makes this untrue).
>
> On the other hand, this forces the need for needless default
> cases in switch statements since the compiler will complain
> if in a switch numLetters above is not taken care of.
>
> So, is this good or bad?[/color]

Bad because:
void foo(Letter);

foo(numLetters) ; // OK?

Also many compilers will issue a warning if you create a switch(Letter)
statement that includes
neither numLetters nor a default case.

A better variation (for the usual enums without initializers) is:
enum Letter { X, Y, Z, FIRST_LETTER=X, LAST_LETTER=Z };
This way you don't introduce a value that is outside the proper range and
FIRST_LETTER is sometimes useful when you want to pass them as ints and
use 0 as an undefined value (if you init X=1)
[color=blue]
>
> Opinions welcome,
>
> Regards,
>
> Neil[/color]

[Nick Hounsome]

Re: specifying enumeration size as member: good or bad


"Neil Zanella" <nzanella@cs.mu n.ca> wrote in message
news:b68d2f19.0 404021410.47847 bd@posting.goog le.com...[color=blue]
> Hello,
>
> I have seen code that does the following:
>
> enum Letter { X, Y, Z, numLetters };
>
> Is this considered good or bad code? On one hand, the code seems more
> maintainable because no matter whether letters are added or removed
> the value of numLetters will be correct (as long as no letter is
> given a number with the equal sign which makes this untrue).
>
> On the other hand, this forces the need for needless default
> cases in switch statements since the compiler will complain
> if in a switch numLetters above is not taken care of.
>
> So, is this good or bad?[/color]

Bad because:
void foo(Letter);

foo(numLetters) ; // OK?

Also many compilers will issue a warning if you create a switch(Letter)
statement that includes
neither numLetters nor a default case.

A better variation (for the usual enums without initializers) is:
enum Letter { X, Y, Z, FIRST_LETTER=X, LAST_LETTER=Z };
This way you don't introduce a value that is outside the proper range and
FIRST_LETTER is sometimes useful when you want to pass them as ints and
use 0 as an undefined value (if you init X=1)
[color=blue]
>
> Opinions welcome,
>
> Regards,
>
> Neil[/color]

[Richard Herring]

Re: specifying enumeration size as member: good or bad

In message <4nnbc.27205$Nu 3.7850507@news4 .srv.hcvlny.cv. net>, Claudio
Puviani <puviani@hotmai l.com> writes[color=blue]
>"Neil Zanella" <nzanella@cs.mu n.ca> wrote[color=green]
>> Hello,
>>
>> I have seen code that does the following:
>>
>> enum Letter { X, Y, Z, numLetters };
>>
>> Is this considered good or bad code?[/color]
>
>I consider it to be bad because it breaks the cohesion of the type. The type
>'letter' now represents two separate concepts: letters AND the number of
>possible letters.[/color]

But number-of-letters is just a way of thinking. Rename the extra item:

enum Letter { X, Y, Z, endOfLetters };

Now it's just an example of the all-pervasive C++ one-past-the-end
paradigm.
[color=blue]
> If you had a set (in the generic sense, not the standard
>container) of letters, this type indicates that the set could contain
>'numLetters' as a valid member, which is completely absurd.[/color]

But if you had, say, std::vector<cha r> v, you wouldn't complain because
v.end() didn't point to a letter, would you?
[color=blue]
>'numLetters'
>should be a separate constant. Both the enum and the constant -- along with
>various utility functions -- could be kept in a common namespace or class if
>they need to be packaged together, but never in the same enum.
>[color=green]
>> On one hand, the code seems more maintainable because
>> no matter whether letters are added or removed the value
>> of numLetters will be correct (as long as no letter is
>> given a number with the equal sign which makes this untrue).[/color]
>
>It's a lot more maintainable to change one constant if the enum is changed[/color]

Even more maintainable not to have to change anything else...
[color=blue]
>than to track down errors because the enum is incorrectly designed.[/color]

If you consider that to be an incorrect design, of course ;-)[color=blue]
>[color=green]
>> On the other hand, this forces the need for needless default
>> cases in switch statements since the compiler will complain
>> if in a switch numLetters above is not taken care of.[/color]
>
>At the very least.[/color]

But not all enums are used in switches.[color=blue]
>[color=green]
>> So, is this good or bad?[/color]
>
>Definitely bad.
>[/color]
_Sometimes_ bad.

--
Richard Herring