From -9076642943059967358 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,ccb40040597f37a7 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-03-11 10:56:58 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: allan_w@my-dejanews.com (Allan W) Newsgroups: comp.std.c++ Subject: Re: Extending enums (was Re: Forward declaration of enum) Date: Tue, 11 Mar 2003 18:56:56 +0000 (UTC) Organization: http://groups.google.com/ Lines: 82 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <7f2735a5.0303111038.26dd239a@posting.google.com> References: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: mail2news.demon.co.uk 1047409017 1756 10.0.0.1 (11 Mar 2003 18:56:57 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Tue, 11 Mar 2003 18:56:57 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.05) id 18sovn-0000SB-00 for mail2news@news.news.demon.net; Tue, 11 Mar 2003 18:56:55 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id FAA04140; Wed, 12 Mar 2003 05:56: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-Newsgroups: comp.std.c++ X-NNTP-Posting-Date: 11 Mar 2003 18:38:37 GMT X-Spam-Status: No, hits=-8.4 required=5.0 tests=NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.41 Xref: archiver1.google.com comp.std.c++:18259 > kgwzamboni-news@zambonistiscan.com writes > >On Tue, 4 Mar 2003 16:45:34 UTC, nagle@animats.com (John Nagle) wrote: No, John Nagle did not write the next few lines, kgwzamboni-news did. (KGW?) Giving a source not followed by >quote'd lines, implies that the text which immediately follows was written by someone else. A false implication, in this case. kgw, please try to be careful with your attributions -- I don't know if Mr. Nagle would be upset quoting ideas to him, but I would! > >How about also making them more like real types. > >enum Color( Red, Orange, Yellow ); > >enum Fruit( Orange, Apple, Grapes ); > > > >Except when assigning them directly to ints, the compiler is capable > >of determining which Orange it is. > >For that case allow the cast like Color(Orange). > > > >Then dumb things like "Color x = Grapes;" would be flaged. > francis.glassborow@ntlworld.com (Francis Glassborow) wrote > However we hit the same problem that we have with forward declaration, > that of different enums having different sizes in C++. > > Yes I know derived class objects are usually larger than their base > class objects, but in the case of enums we have the problem of > enumeration constants. Suppose in the above example that Colour > instances have a size of 1 and Fruit ones have a size of 2. What should > be the size of Red before the definition of Fruit, and after it? Since Fruit is not derived from Color, I would say that there should be no effect. Recasting your question to a more appropriate heirarchy: enum lowcolors { red, green, blue, // lots more here... but not so much as to force lowcolors // to be larger than the default size for enums max }; enum highcolors { pink = lowcolors::maxvalue, magenta, cyan, // Lots more here... enough to force // sizeof(highcolors)>sizeof(lowcolors) maxvalue }; Now you're asking if the existance of enum highcolors ought to have any effect on enum lowcolors. Of course, if anyone says that it should, they're throwing away the entire concept of seperate compilation... I suppose a simpler way to handle the difference is to add some code (syntax left for another day) that tells the compiler that it's okay to implicitly convert a lowcolor into a highcolor. I agree with Lawrence Rust that the idea of using inheritance seems obvious... and I agree with Hyman Rosen that when examined more deeply, it's actually backwards from normal inheritance relationships. In any case, we cannot use a highcolor where a lowcolor is expected, but perhaps we could arrange things so that a lowcolor could be used wherever a highcolor is expected. highcolor h1 = pink; // Of course highcolor h2 = blue; // Implicit conversion lowcolor L1 = blue; // Of course lowcolor L2 = pink; // ?Always undefined? We might allow that last statement when sizeof(highcolor) happens to equal sizeof(lowcolor). Or, we might make it always illegal. --- [ 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 ]