Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!rutgers!clyde!ima!haddock!karl
From: karl@haddock.UUCP (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: enum - enum ?
Message-ID: <544@haddock.UUCP>
Date: Thu, 11-Jun-87 17:55:13 EDT
Article-I.D.: haddock.544
Posted: Thu Jun 11 17:55:13 1987
Date-Received: Sat, 20-Jun-87 12:49:08 EDT
References: <139@starfire.UUCP> <4400002@hpclla.HP.COM> <1191@ius2.cs.cmu.edu>
Reply-To: karl@haddock.ISC.COM.UUCP (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 34

In article <1191@ius2.cs.cmu.edu> edw@ius2.cs.cmu.edu (Eddie Wyatt) writes:
>I just tried [using "++" and "--" for successor and predecessor] with my C
>complier and it didn't allow an enum variable in the increment statement.  I
>guess they wanted to avoid the semantic issues here.  Example [given the
>declaration: enum color {red=1, blue=4, green=5};]
>    rgb = red;  rgb++;
>does rgb == blue or red+1?

Clearly it should be red+1, which should have the value (enum color)2.
However, since this value is not a declared member of the set, one could argue
that the result is undefined.

>[mar@hpclla.HP.COM (Michelle Ruscetta) writes:]
>>I would like to have enums and enum constants be flexible, but I also would
>>like the extra type-checking for enums; otherwise I might as well use
>>#define's for compile-time constants.
>
>I view C enumerations a as facility for defining set of interrelated
>constants.  I use them for program readability, not for any extra
>semantic meaning that is attached.

Yes, it does add to readability, but I believe in typechecking too.  I use
"enum" even though "int" will do the same job and more, for the same reason I
use "while" instead of "goto": I've observed that programs that can get away
with the weaker construct are more likely to be correct.  In my programs,
using an uncasted enum in an int context is a bug; naturally I prefer the
compiler (either cc or lint) to warn me.

In fact, while I acknowledge that "typedef creates a new name for a type, not
a new type; it does not imply dimensional analysis" (paraphrased from K&R),
I'd like to have a feature that *does* produce a new type.  (Though I'm not
yet sure what operators should be allowed on such a new type.)

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint