Path: utzoo!attcan!uunet!mcsun!ukc!dcl-cs!aber-cs!odin!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.lang.c++ Subject: Re: Static consts within classes? Message-ID: Date: 2 Jul 90 22:25:25 GMT References: <10460@batcomputer.tn.cornell.edu> <274@taumet.com> <31284@cup.portal.com> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 91 In-reply-to: wmmiller@cup.portal.com's message of 30 Jun 90 17:00:17 GMT Posting-Front-End: GNU Emacs 18.55.4 of Thu Nov 23 1989 on athene (berkeley-unix) In article <31284@cup.portal.com> wmmiller@cup.portal.com (William Michael Miller) writes: 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. Also subscript checking is incredibly valuable, and yet! This is C/C++... > 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. But the matter of enums has been open to debate... A foolish hobgoblin is the mind of little consistencies :-). > 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, This is *only* because of a language misdesign problem; using 'static' to mean 'class object member' preempts its use to specify linkage, and thus the rule that static members always have external linkage. An alternative could have been that the linkage of class members of any type is specified in its *definition*, not in its declaration in the class definition. This is what GNU C++ implements, albeit only partially (e.g. only for function members). If we could have class object (instead of instance) const members with internal linkage, they would be "bodiless" consts like every other. > 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 ... }; The crucial point is that in my example an ordinal has sizeof (char unsigned), and in yours we do not know -- the implementation may or may not pack it (a way to control the size of an enum entity is to use bitfields in a struct, but here we have an array). C/C++ tend to be languages in which you want to control the storage you allocate to things, more than one in which you want type security -- it is *not* Pascal. So we have signed and unsigned whose sizes we can control, and enums where we cannot. We could say that enums, being integral types, should be subject to the same shortening and lengthing attributes (char, short, long) as signed and unsigned (well, I know that regrettably char has become more of a type in C++ 2.0 :-/), but again maybe it would be simpler to avoid special casing enums, and just change the rule about typedefs, so that new integral types could be introduced that way (which would have other positive consequences, like allowing operators on the new types, without requiring embedding in a class), etc... The flexibility of C++'s class definitions allows them to work nearly as well as subtyping. Precisely... In summary: the current C++ definition can be explained and maybe even justified, but certainly not excused in many areas, like the difficulties with members of the class object (which class object? :->) caused by overloading the keyword static. And departing from C in one area (enums) and not another (typedef). And... -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk