Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!adm!cmcl2!lanl!lambda!scp From: scp@raven.lanl.gov (Stephen Pope) Newsgroups: comp.lang.c++ Subject: Re: stronger type checking of enums Message-ID: Date: 4 Mar 89 00:32:25 GMT Sender: news@lanl.gov Reply-To: jas@ernie.Berkeley.EDU.UUCP (Jim Shankland) Organization: Los Alamos National Laboratory, NM Lines: 24 In article dld@F.GP.CS.CMU.EDU (David Detlefs) writes: >Having the greatest respect for Dr. Stroustrup's judgement, >I'm sure there is a good reason for [not having stronger type checking >of enums], but I can't think of what it might be just sitting here. As in C, enums aren't a *real* data type. Furthermore, cfront insists on treating char, short, int and enum as equivalent (thus there is no operator << (ostream&, char), and never a possibility of having both SomeClass::SomeClass(char) and SomeClass::SomeClass(int) constructors at the same time). This can make coding for some classes rather a drag, and at best forces one to often create little sizeof(int) classes were enums would have sufficed. (little enum Booleans with operators << and >> handling the strings "true" and "false" seem real nice, until you realize you must make them a class, and supply a base set of unary/binary operators). G++ is at least willing to recognize the differences amongst all these types, but alas the *standard* coersion rules will always silently convert one enum type into another enum type, ala C. Making them distinct, without standard coersions, would make many other things rather difficult and even ugly. Stephen Pope scp@santafe.edu