Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.lang.c
Subject: Re: enum - enum ?
Message-ID: <20540@sun.uucp>
Date: Sat, 6-Jun-87 16:38:28 EDT
Article-I.D.: sun.20540
Posted: Sat Jun  6 16:38:28 1987
Date-Received: Sun, 7-Jun-87 10:33:10 EDT
References: <139@starfire.UUCP> <516@haddock.UUCP>
Sender: news@sun.uucp
Lines: 53

> Personally, I think I'd be happy to have both enums and chars behave like
> pointers arithmetically (e.g.  char+int == char, enum-enum == int, other
> combinations illegal), provided there's also a type "byte" ("short short"?)
> for arithmetic usage.

I tend to agree (I would prefer "short short" as the adverb here),
having learned that Type Systems Are Your Friend and that, in most
cases, there is no benefit to be gained from promiscuously flouting
the rules of the type system (and significant benefit to be gained by
following those rules - just running "lint" on code, including
kernels, before building and testing them has often turned up
errors).

> But if enums are too weakly typed, what's their advantage over ints?

I hope certain legal but dubious uses of "enum"s will at least generate
warnings even from X3J11-conforming compilers; for example, coercing
something of type "enum foo" to something of type "enum bar".  This
might not be as good at catching errors as forbidding those uses, but
at least it means that the use wouldn't pass without comment.

> Given the suggested "pointer-like" semantics for arithmetic, and the
> ability to declare an array indexed by enums (or other types!), I could
> find more use for them.
> int hue[enum color] = { RED: 0x00F, GREEN: 0x0F0, BLUE: 0xF00 }; /* I wish */

I agree that it would be nice to support declaring arrays indexed by
"enum"s.  (What "other types" would be indices?  "char", presumably;
the only other types I could see would be subrange types - are you
proposing adding them to C?)  It fits the model of an array as a
function from the set of all values of the index type to all values
of the base type, although to properly implement that model subrange
types would be needed (an array indexed by "int", in this model,
would have the set of all values of type "int" as its domain, which
implies a VERY big array).

One interesting possibility is suggested by the fact that the set of
numerical encodings of "enum" values need not be "dense", and thus
that

	enum cookie { chocolate_chip = 1, oreo = 10, oatmeal = 100 };
	int price[enum cookie];

might cause "price" to be a sparse array, with lookups in that array
done by some technique other than indexing.  This is analogous to
"switch" statements; the compiler selects different implementations
based on the set of values used, with indexing used for a
sufficiently "dense" set, various combinations of hashing and
table-search used for less-"dense" sets, and a cascade of comparisons
used for other sets.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com