Path: utzoo!attcan!uunet!husc6!cmcl2!rutgers!att!ihlpb!nevin1
From: nevin1@ihlpb.ATT.COM (Liber)
Newsgroups: comp.lang.c++
Subject: Re: Improved switch statement
Message-ID: <9264@ihlpb.ATT.COM>
Date: 23 Dec 88 03:23:02 GMT
References: <6590072@hplsla.HP.COM> <1106@etive.ed.ac.uk> <33528@bbn.COM> <1907@ogccse.ogc.edu> <574@redsox.UUCP> <9245@ihlpb.ATT.COM> <781@auspex.UUCP>
Reply-To: nevin1@ihlpb.UUCP (55528-Liber,N.J.)
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 27

In article <781@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes:

>Well, offhand I'd think a program defining "==" operator that didn't act
>like an equality operator would be a good candidate for an "Obfuscated
>C++ Code" contest; I'd *strongly* suggest they pick some other operator.

But part of the beauty of C++ is that you don't have to define
operator== as the *C* equality operator!

>Is there some good reason why one would want to define "==" as an
>operator that didn't behave like a "comparison for equality" operator? 

Suppose I defined operator== for a class (call it ihlpb) that, when
comparing two instances of ihlpb (call them nevin and liber) in a
"nevin == liber" manner, returns a NULL pointer if false, or a pointer
to liber if true.  This equality operator does not have the property of
being commutative, as is consequently not the same as the C equality
operator.

Since C++ makes no guarantee on how a given operator can be defined, it
would be very bad to add a selection statement to the language which is
*implicitly* dependent on the semantics of an operator.  One of the
strong points of C++ is that the code is more self-documenting;
generalizing the switch statement in this manner would go against this
goal.
-- 
NEVIN ":-)" LIBER  AT&T Bell Laboratories  nevin1@ihlpb.ATT.COM  (312) 979-4751