🚀 go-pugleaf

In article <25740@cornell.UUCP> deb@cs.cornell.edu (David Baraff) writes:
>I had a function that was of type 'boolean', but accidentally
>returned some other enum constant.
>With strong(er) type checking the compiler could easily
>have determined I had a type error.
>
>Why shouldn't enum's have their own type, and why shouldn't
>the compiler strongly type enum expressions?
>
I have a very similar problem with both enum's and int's. I'm trying to
write some portable code that will have data written to disk. I am using
overloaded functions to effect an XDR type concept. The problem is that
on a PC using Zortech C++ an "int" is mapped onto a "short". If this mapping
is consistent with the C++ spec then on a 32-bit machine an "int" will
map onto a "long". In order to avoid a portability problem I always have
to write a 32-bit integer to disk because I can't have 3 functions for
dealing with integer (int, short, and long) which can then be uniquely
identified. Additionally and enum type automatically maps onto one of
these overloaded functions, but I'm not sure which one (I'm guessing
short).

The solution I have is fine and but there could be other problems I run
into later where having int be a unique type from short and long would
be useful. Does anyone else agree?

Dan Mutchler

In article <25740@cornell.UUCP> deb@cs.cornell.edu (David Baraff) writes:
>I'd like to make a case for stronger type checking of enum's.

I agree that this would be very nice. But it does introduce some
questions.  Array indexing.

One would probably also want to be able to declare:
	enum Color {r,g,b};
	int	a[Color];

Would you also add and Ord () function?

If you can do these things, then why not also allow subranges?  How
about integer subranges?  (Hmm... Begins to sould like Pascal?).

I like the suggestion, but you can see how one might get carried away
adding 'features' to the language.

						Lewis.




"OS/2: half an operating system for half a computer."

In Real Life:		Lewis Gordon Pringle Jr.
Electronic Mail:	lpringle@labs-n.bbn.com
Phone:			(617) 873-4433

In article <36748@bbn.COM> lpringle@labs-n.bbn.com (Lewis G. Pringle) writes:
>In article <25740@cornell.UUCP> deb@cs.cornell.edu (David Baraff) writes:
>>I'd like to make a case for stronger type checking of enum's.
>
>I agree that this would be very nice. But it does introduce some
>questions.  Array indexing.
>
>One would probably also want to be able to declare:
>	enum Color {r,g,b};
>	int	a[Color];
>[[and goes on to talk about ord() and Pascal]]

Enums as presently constructed give one a false sense of security.
Aside from such wonderful questions as strong type checking, we
have to deal with stupid issues like
	enum Color { red, green, blue, orange } ;
vs.
	enum Fruit { plum, orange, avocado, kumquat } ;

The intent of enum seems to be a primitive user-defined class --
a named type with a list of specific values which it may take.

Let's keep enum in it's present form but just tighten up the
checking.  It looks like a prime case where C++ can improve
C without breaking.