Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!gatech!udel!rochester!pt!ius2.cs.cmu.edu!edw
From: edw@ius2.cs.cmu.edu (Eddie Wyatt)
Newsgroups: comp.lang.c
Subject: Re: enum - enum ?
Message-ID: <1191@ius2.cs.cmu.edu>
Date: Wed, 10-Jun-87 10:53:07 EDT
Article-I.D.: ius2.1191
Posted: Wed Jun 10 10:53:07 1987
Date-Received: Sat, 20-Jun-87 06:03:35 EDT
References: <139@starfire.UUCP> <4400002@hpclla.HP.COM>
Organization: Carnegie-Mellon University, CS/RI
Lines: 79

In article <4400002@hpclla.HP.COM>, mar@hpclla.HP.COM (Michelle Ruscetta) writes:
> 
> >I think it would be reasonable for enum - enum to be an integer value,
> >just as ptr - ptr is, and for similar reasons; you want the 'distance'
> >between them.  This would also imply  enum + int  == enum  and  enum++ is ok
> 
> The following statements assume the declaration: 
> 			enum color {red=1, blue=4, green=5};
> 			enum fruit {apple=1, orange=4, grape=5};
> 
> for clarification: color is an enum; red is an enum constant;
> 
> What is the use of an expression such as red++  ??
					   ^^^

	I think you mean a variable of type color.

   color rgb;

   rgb++ - could be used as the successor function
   rgb-- - cound be used as the predessor

  I just tried this 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

	rgb = red;
	rgb++;
	does rgb == blue or red+1?


> 
> Enum constants are integer constants - why would you want to allow the 
> modification of a constant (ie: red++) - might as well use ints.

	No one should or can modify a constant in C. Again I think you
	mean a enum variable.
> 
> I agree that enums in general should be implemented as a special case of
> integers - allowed wherever integer constants are allowed, but with extra
> restrictions regarding assignment of two different enums (color = fruit)
> and addition of enums or enum constants.
> 
> Subtracting two enum constants or adding a integer to an enum constant could 
> be useful, but what would you use the addition of two enum constants for?

	type enum {offset1 = 3, offset2 = 5, offset3 = 6} offsettype;
	type enum {index1 = 4, index2 = 9, index3 = 9} index;

	int where = offset1*sizeof(mytype) + index2; 
			/* array indexing function ^ */
	
> 
> Should enum_constant - enum_constant only be allowed if both enum constants
> are elements of the same enum type?
> 
> 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.
> type.


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

	typedef enum {PEUTOKEN, PEUFRAME, PEUFFRAME ...} PARSEERRORTYPE;

 A lot more meaningful than 

	#define PEUTOKEN 	0
	#define PEUFRAME 	1
	#define PEUFFRAME 	2
	.....

-- 
					Eddie Wyatt

e-mail: edw@ius2.cs.cmu.edu