portegys@ihuxv.UUCP (06/22/83)
I was suprised to find out recently that C does not allow
identical enumeration names within different data types. I
am working under UNIX 5.0 on a VAX 11/780. Here is an example
of what I mean:
----------------------------------------------
typedef enum {
GREEN,
RIPE,
ROTTEN
} APPLE;
typedef enum {
SOUR,
JUICY,
ROTTEN
} ORANGE;
main() {
ORANGE fruitx;
APPLE fruity;
fruitx = ROTTEN;
fruity = ROTTEN;
}
----------------------------------------------
This program will not compile, due to the redeclared symbol ROTTEN.
I think this is a deficiency of C, since the two values of ROTTEN
apply to different data types.
Tom Portegys, BTL IH, ihuxv!portegysken@turtleva.UUCP (06/23/83)
Since when did C have enumerated type entities?
pgf@hou5f.UUCP (06/23/83)
Could someone please expand on the usefulness of the "enum" type in C? I know how they are used in Pascal, but even there they aren't printable (i.e. easily converted to strings). Is the enum type really more useful than using #define? Can I loop on them? Compare them? I know I can't print them. Paul Fox ABI Holmdel, ihnp4!hou5f!pgf
mat@hou5e.UUCP (06/24/83)
Well, regarding the enum's ... I don't think that there would be much, if any efficieny difference over, say, #defines. They are, if well implemented in a language, one more good way to aid communication and make strong typing available to the programmer when she thinks that it is needed. Ada has some good ideas here ... the disambiguate in the case of (hope this is close to being right .. I DON'T use enum's) typedef enum ( RED, GREEN, ROTTEN ) APPLES; typedef enum ( FLORIDA, CALIFORNIA, ROTTEN ) ORANGES; one would write APPLES.ROTTEN or ORANGES.ROTTEN. ADA (Yes, a TM of US DOD, et&c) has a LOT of good ideas. Also a few very bad ones, and in critical places. And a lot of other problems (which should get discusssed in net.lang). One area that received a lot of attention (ie nitpicking from academia) was disambiguation in various forms. If there is a successor to C I hope that its designers use the good stuff out of ADA, just as (it seems) C used good stuff from the FORTRAN/PL\/1 heritage. I don't think enums, as implemented, are either well enough designed or well enough implemented to be integrated into one's standard repertoire of C constructs and techniques. (My opinions only ... they should not be construed to represent opinions of either my employer or client) Mark Terribile (sometime Duke of deNet) Spiridellis & Associates (A member of the Cap Gemini Sogetti USA Group) On contract at American Bell, Holmdel hou5e!mat
pdl@root44.UUCP (06/26/83)
For the information of those who STILL don't realise it, C has has the `enum' keyword and associated stuff since V7 (see the addendum to the C reference manual sent out with V7). (Personally, I have never used enums: I might possibly if they did sensible things, like being stored in the smallest possible size, instead of always being treated as an int, which seems a bit silly).
kurt@fluke.UUCP (06/26/83)
The thing about the members of an enumerated type is that they are LITERAL CONSTANTS. Wanting to use a particular identifier to denote a member of more than one enumeration should be viewed in the same way as wanting to use a particular numeric literal (like 1 or 16) to denote more than one value. Just because identifiers used as members of an enumeration are spelled differently than literal numeric constants does not mean they are semantically any different. For extended discussion of this topic try: "Enumerations in Pascal, Ada, and Beyond",Moffat, SIGPLAN Notices(16)2 pp 77-82, Feb 1981 "Another Look at Enumerated Types",Harland & Gunn, SIGPLAN Notices(17)7 pp 62-71, July 1981 Kurt Guntheroth Digital Service Products Software John Fluke Mfg. Co., Inc.
ucbesvax.turner@ucbcad.UUCP (06/29/83)
#R:turtleva:-20300:ucbesvax:4800015:000:2321 ucbesvax!turner Jun 28 23:28:00 1983 Who is controlling the definition of the C language? For years, I'd say that S.C. Johnson was the main force, with some factionalism surrounding various issues within the community of original definers. Now, I'm not sure. This language is probably the strongest link between the Berkeley and Bell UNIX versions. C has very much the flavor of an evolving language, even now. I find it almost intolerably messy in places, although I will confess a liking for the reasoning behind the construction of arrays of pointers to functions returning ints. typedef is a hack, but at least it gives you a handle on C's type constructions, once you figure them out. It hands you back a small piece of what it is hiding, which is one way for a language to evolve. To give away too much can cloud a revelation's uses with issues of safe packaging--an encumbrance. To give give away too little is to add an "ad hoc hack"--a trivialization. I think enum types fall into the latter category. They allow stronger typing, but in a counterproductive way. Bit fields are getting some use, and are even implemented efficiently on some machines, although I've never seen a convincing argument for the conservatism of alignment (to the next int, if I recall), or the reasons against arrays of bit fields. But they don't nearly defeat themselves. By far the best things to happen to happen to C in recent years are (1) "flexnames"--longer identifiers, and (2) multiple use in different struct/union definitions of the same field name. These two events have something about them of tree roots cracking the pavement they grow under. Structure assignment is sometimes useful. Some of these changes are documented in "The C Reference Manual" which, at our site, has an "appendix" (not marked as such; in fact, no page number appears) called "Recent Changes to C". It documents structure assignment and enum types. It is dated November 15th, 1978. No author is named--although there is an intimation that it is the author of the PDP-11 C compiler. I learned of the other extensions by word of mouth. Or by accident. From the hissing embers of what few neurons that I have remaining, I issue a plea for clarification. From a reliable source, that is. Hissing Only Slightly, Michael Turner ucbvax!ucbesvax.turner