garry@batcomputer.TN.CORNELL.EDU (Garry Wiegand) (05/28/86)
In a recent article sher@rochester.UUCP (David Sher) wrote: >I just tripped over another "feature" of c++. >This feature is that enums are not types. >They look like types but really are synonomous with sets of >constant definitions and typedefs of ints. This strikes me as wrong... I am reminded of a long-standing pet peeve of mine: I can get type-checking on structures and unions. I can get type-checking on primitive types (int, float, ...). I CANNOT get type-checking on datatypes declared via 'typedef' EXCEPT in terms of their underlying types. (I assume this all is still true in the new language standard.) What I would like is for typedef names to be considered by the compiler as DIFFERENT from the underlying types. The compiler should then allow an implicit (or explicit) cast back and forth between the derived and underlying types - this will avoid breaking existing code. The improvement over the current state of things will happen when I ask the compiler "please tell me about possibly nasty implicit casts!" Note 1: people who are in the habit of doing things like: typedef unsigned char ubyte; and who want to use this new feature will have to switch to: #define ubyte unsigned char unless they really want "ubytes" to be non-computable. Note 2: At some point (of course) you have to give a value to a derived- type variable. If you compile habitually with the new message turned on, then in such a situation you'll have to use an explicit cast. Note 3: The same principle could be extended to structures that are equivalent though not identical and to enum's. Is it reasonable? Is it hard to implement? Comments? (Followups to net.lang.c, pls). -- garry wiegand (garry%cadif-oak@cu-arpa.cs.cornell.edu)