Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!necntc!ima!haddock!karl
From: karl@haddock.UUCP (Karl Heuer)
Newsgroups: comp.lang.c
Subject: type-indexed arrays (was: enum - enum ?)
Message-ID: <526@haddock.UUCP>
Date: Tue, 9-Jun-87 10:18:05 EDT
Article-I.D.: haddock.526
Posted: Tue Jun  9 10:18:05 1987
Date-Received: Fri, 12-Jun-87 03:30:59 EDT
References: <139@starfire.UUCP> <516@haddock.UUCP> <20540@sun.uucp>
Reply-To: karl@haddock.ISC.COM.UUCP (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 49

In article <20540@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes:
>[haddock!karl (Karl Heuer) writes:]
>>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?)

Maybe someday -- but no, that wasn't what I was thinking.  Some machines can
support a[short] with no trouble, but that would raise the question of which
types a conforming implementation is *required* to support (and hence can be
used in a portable program)...

>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.

I glad you posted this -- I was going to mention the same idea myself, but I
prefer the feedback so I can tell someone is listening to my ravings.  :-)
In your example, the implementation might choose to allocate three ints and
use a cascade of comparisons (actually, one comparison against "oreo" would
suffice).

Now, we could assert that a conforming implementation must support *all* types
as subscripts, and that "int a[int]" will, if necessary, cause some sort of
"smart" lookup.  The problem now is that the amount of space required is not
known at compile time.  If the compiler is going to use a hash table, it can
probably make good use of a "hint" from the programmer.  (Which probably means
another new keyword.  Ugh.)

Incidentally, I am not suggesting that this feature be incorporated into the
new standard -- I realize there's very little hope for that.  However, I *do*
believe it is a good idea (at least for enum), and would like to see it
implemented as an extension.  If it catches on, it may be a candidate for the
__STDC__==2 release.

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