From 8500116156440916702
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,ccb40040597f37a7
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 2003-03-11 09:15:05 PST
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.alt.net!comp-std-cpp-robomod!not-for-mail
From: Niklas Matthies <comp.std.c++_2003-03-11@nmhq.net>
Newsgroups: comp.std.c++
Subject: Re: Extending enums (was Re: Forward declaration of enum)
Date: Tue, 11 Mar 2003 11:14:12 CST
Organization: Team Rocket
Lines: 61
Approved: Fergus Henderson <fjh@cs.mu.oz.au>, moderator of comp.std.c++
Message-ID: <slrnb6qkr5.1f4g.comp.std.c++_2003-03-11@nmhq.net>
References: <PNE21WKuwwiy-pn2-2YXh1K9td7dn@zamboni.stiscan.com> <memo.20030310212425.56925C@brangdon.madasafish.com>
Return-Path: <devnull@stump.algebra.com>
X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f
X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov)
Delivered-To: std-c++@ncar.ucar.edu
X-Orig-NNTP-Posting-Host: gen019.n002.c03.escapebox.net (213.73.82.19)
X-Orig-X-Trace: fu-berlin.de 1047352165 66276380 213.73.82.19 (16 [27100])
X-Reply-To: niklas dot matthies at nmhq dot net
X-Editor: Vim 5.3
X-Operating-System: Debian GNU/Linux 2.2.15 i586
User-Agent: slrn/0.9.7.4 (FreeBSD)
X-MailScanner: PASSED (v1.2.7 19022 h2B39RiC039588 mailbox4.ucsd.edu)
X-Spam-Status: No, hits=0.2 required=10.0
	tests=FROM_ENDS_IN_NUMS,MISSING_HEADERS,NOSPAM_INC,
	      QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_01_02,USER_AGENT,
	      X_AUTH_WARNING
	version=2.43
X-Spam-Level: 
Xref: archiver1.google.com comp.std.c++:18256

On 2003-03-10 21:44, Dave Harris <brangdon@cix.co.uk> wrote:
> kgwzamboni-news@zambonistiscan.com () wrote (abridged):
>> > It is a bit dangerous to have names whose meaning depends
>> > on context. 
>> 
>> How is it any more dangerous than overloaded function
>> declarations?
> 
> The real problem comes when we have both. With overloaded functions,
> we can figure out the meaning by starting in the middle and working
> out. Thus:
>     func( a, b );
> 
> we first figure out the type of a and b, and then figure out which
> func() is the best match. If we have as enum name which depends on 
> context, then:
>     func( orange );
> 
> we go in the opposite direction: figure out which func() to use and
> then figure out which version of orange it wants. If we have both
> kinds of overloading, we don't really know where to start.
> 
> What you are suggesting here is a pretty major change, because of
> this.

Is this really conceptually different from types with (possibly
multiple) implicit conversions used in overloaded function argument
context?

Say:

   namespace fruit { enum type { orange /* ... */ }; }
   namespace color { enum type { orange /* ... */ }; }

   struct generic_orange
   {
      operator fruit::type () const { return fruit::orange; }
      operator color::type () const { return color::orange; }
   };

   generic_orange const orange = generic_orange();

   void g(fruit::type f);

   void h(fruit::type f);
   void h(color::type c);

   void f()
   {
      g(orange);  // okay
      h(orange);  // ambiguous
   }

-- Niklas Matthies

---
[ 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                       ]