From 138705584557709592 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,ccb40040597f37a7 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-03-13 08:36:56 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: dsp@bdal.de (Daniel Spangenberg) Newsgroups: comp.std.c++ Subject: Re: Extending enums (was Re: Forward declaration of enum) Date: Thu, 13 Mar 2003 16:36:55 +0000 (UTC) Lines: 79 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <3E703B18.7CECBFB6@bdal.de> References: <3E6C739E.9850D2A5@bdal.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: mail2news.demon.co.uk 1047573415 15520 10.0.0.1 (13 Mar 2003 16:36:55 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Thu, 13 Mar 2003 16:36:55 +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 18tVhO-00042B-00 for mail2news@news.news.demon.net; Thu, 13 Mar 2003 16:36:54 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id DAA17483; Fri, 14 Mar 2003 03:36:51 +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-Accept-Language: de X-Newsgroups: comp.std.c++ X-Spam-Status: No, hits=-5.0 required=5.0 tests=QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01, USER_AGENT_MOZILLA_XM,X_ACCEPT_LANG version=2.41 Xref: archiver1.google.com comp.std.c++:18303 Dave Harris schrieb: [snip] > I prefer the openness. This is partly because my local compiler supports > forward enum declarations, so I can write: > > namespace Colour { enum Type; } > > If I tried that with a struct I'd come a cropper on the One Definition > Rule. (I use this language extension a lot - which is part of why I > advocate making it standard.) OK, under these circumstances the usage of namespaces would be preferable. 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. In case of unnamed enumerations this requirement has to fell, of course. Although I think, that such a usage of enumeration members would be very useful and type-save, I don't like its divergence from the C-meaning of enums, so instead of CHANGING the interpretation of enum Colour{ Red, Blue }; 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? > > Why do you think, that Color::Type" is not a convenient identifier? > > It's an invented name, a placeholder purely to satisfy the compiler. I'd > much rather be able to write: > > Colour c = Colour::Red; > > Compare with: > > struct Colour { > const Colour Red, Green, Blue; > }; > > Colour c = Colour::red; But realize, that your given class example is no valid C++! You are using class members of the currently not defined class itself! I think, a proposal, like the above mentioned type extension, would be a cleaner solution to this problem. Yours, Daniel Spangenberg --- [ 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 ]