NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/std/cplus/1174

Internet Message Format | 1992-09-13 | 1.8 KB

Path: sparky!uunet!mcsun!corton!seti!inria.fr!daniel.edelson
From: [e-mail] (Daniel R. Edelson)
Newsgroups: comp.std.c++
Subject: Re: Answers on a postcard
Message-ID: <[e-mail]>
Date: 14 Sep 92 09:00:50 GMT
References: <[e-mail]>
Sender: [e-mail]
Reply-To: Daniel R. Edelson <[e-mail]>
Organization: INRIA -- Institut National de Recherche en Informatique et Automatique -- Rocquencourt, France
Lines: 28

In article <[e-mail]>, [e-mail] (Karl Keyte) writes:
|> ...from a posting on 'comp.lang.c++'
|>
|> In article <[e-mail]>, [e-mail] (Steve Clamage)
|> says:
|> >
|> The implication of what you say is that it is not possible to overload
|> operators maintaining the correct functionality of the operator.  This
|> indeed means that precedence in overloaded operators cannot be maintained
|> if all operands are simply passed as arguments to the function implementing
|> the operator functionality and evaluated in a language independent order.
|> Imagine commonly used "chain" operators such as && and ::.
|>
|> If what is described above is correct, and Mr.Clamage clearly has much
|> experience in the area, then I think we have justification for pressing
|> for a change in this area.  If not, I would ask: How does one overload
|> the comma operator while maintaining its attibutes as an operator?
|>
|> Karl

It seems to me that the ability to look at a comma expression and
infer some semantics from the syntax is a valuable aid
for program readability. This seems to me like an argument for
not permitting the comma operator to be overloaded. Of course,
the logical extension is to then forbid && and || from being
overloaded as well, but this seems unlikely to happen, unfortunately.

[e-mail]