From 3885743976400239494 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,ccb40040597f37a7 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-03-14 09:26:52 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: brangdon@cix.co.uk (Dave Harris) Newsgroups: comp.std.c++ Subject: Re: Extending enums (was Re: Forward declaration of enum) Date: Fri, 14 Mar 2003 17:26:51 +0000 (UTC) Lines: 71 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <3E703B18.7CECBFB6@bdal.de> X-Trace: mail2news.demon.co.uk 1047662811 20860 10.0.0.1 (14 Mar 2003 17:26:51 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Fri, 14 Mar 2003 17:26:51 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.12) id 18tsxG-0005QI-00 for mail2news@news.news.demon.net; Fri, 14 Mar 2003 17:26:50 +0000 X-Received: by mulga.cs.mu.OZ.AU id EAA06366; Sat, 15 Mar 2003 04:26:46 +1100 (EST) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Path: comp-std-cpp-robomod!not-for-mail X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Delivered-To: std-c++@ncar.ucar.edu X-Newsgroups: comp.std.c++ X-Reply-To: brangdon@cix.co.uk X-Orig-NNTP-Posting-Host: pc1-clif1-6-cust113.nott.cable.ntl.com (80.4.200.113) X-Orig-X-Trace: fu-berlin.de 1047597984 69246107 80.4.200.113 (16 [57443]) X-Spam-Status: No, hits=-5.6 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Xref: archiver1.google.com comp.std.c++:18311 dsp@bdal.de (Daniel Spangenberg) wrote (abridged): > But to my mind, it would be more consistent, if the definition > > enum Colour{ Red, Blue }; > > would be interpreted, such that naming their individual colours would > enforce us to write Colour::Red and Colour::Blue. But this breaks too much existing code. My proposal allows this syntax but doesn't require it. > I would propose the *addition* of a enumclass /classenum written as > > enumclass Colour{Red, Blue}; > > where all members are must be *static* members, which might be either: > > - static constants (which means the individual colours) > - typedefs > - maybe member functions (only those, which in normal classes would be > static functions) > > What about this? It seems very complicated and I don't understand the ramifications to say whether the benefit is worth it. > But realize, that your given class example is no valid C++! You > are using class members of the currently not defined class itself! So add some references. This: struct Colour { static const Colour &Red, &Green, &Blue; }; Colour c = Colour::Red; compiles at http://www.comeaucomputing.com/tryitout/ > I think, a proposal, like the above mentioned type extension, would be a > cleaner solution to this problem. I don't understand what you dislike about my proposal. In other words, to allow: enum Colour { Red, Orange, Yellow }; enum Fruit { Orange, Apple, Grapes }; // OK. Colour c1 = Red; // OK. Colour c2 = Orange; // Error - ambiguous. Colour c3 = Colour::Orange; // OK. An enum creates a namespace and also adds an implicit using-declaration for that namespace. This adds no new keywords, and as far as I know breaks no existing code. Dave Harris, Nottingham, UK | "Weave a circle round him thrice, brangdon@cix.co.uk | And close your eyes with holy dread, | For he on honey dew hath fed http://www.bhresearch.co.uk/ | And drunk the milk of Paradise." --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]