🚀 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