Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!usc!apple!portal!cup.portal.com!wmmiller From: wmmiller@cup.portal.com (William Michael Miller) Newsgroups: comp.lang.c++ Subject: Re: Static consts within classes? Message-ID: <31284@cup.portal.com> Date: 30 Jun 90 17:00:17 GMT References: <10460@batcomputer.tn.cornell.edu> <274@taumet.com> Organization: The Portal System (TM) Lines: 54 pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > what is not possible is to use non enums where an enum *must* be > used. But is that important? Yes, it's quite important. An enumeration defines certain values as being the only ones allowed. Requiring an explicit cast to convert a non-enum value to an enum type is very valuable in insuring that you don't use a value that's outside the set of allowable ones. The presence of casts means you cannot be as type-secure in C++ as you can in Pascal, for instance, but making enums distinct types and forbidding automatic conversions to them is a major help in making things as secure as possible. The fact that automatic conversion *from* enum types is defined does not seem to me to be a major drawback, as the type to which you are converting is less constrained than the enum -- promotion is an integral part (excuse the pun) of C, and it's pretty reasonable. > the loss of length specificaiton is bad; what > happens in practice is that one ends writing things like: > > enum { one, some, many; }; > typedef char unsigned ordinal; > ordinal thumbrule[CASES] = { one, one, some, one, many ... }; I don't understand -- perhaps you've omitted the context which requires writing things this way, but it would seem much more natural to write enum ordinal { one, some, many }; ordinal thumbrule[CASES] = { one, one, some, one, many ... }; > But the two things are essentially equivalent, and the former requires > less special casing. They (static const members and nested enum types) are *not* equivalent: the members take up storage and are runtime values, requiring addressing and subject to being accidentally overwritten, while the enum values are compile-time quantities that can be used in, for example, immediate instructions and impossible on most computers to overwrite. We've already discussed the type issues distinguishing the two. I didn't understand the comment about "less special casing;" they do require *more* typing (keyboarding), however. > If you like this kind of type security, why not lobby to make typedef's > introduce new types instead of synonyms for old types? There is a place for both synonym type definition and derived type definition; it's a matter of debate which is more useful, but what is not open to debate is that synonym type definition is what we've inherited from C. The flexibility of C++'s class definitions allows them to work nearly as well as subtyping. ------------------------------------------------------------------------------ William M. Miller, Glockenspiel, Inc.; P. O. Box 366, Sudbury, MA 01776-0003 wmmiller@cup.portal.com BIX: wmiller CI$: 72105,1744