home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.c++
- Path: sparky!uunet!spool.mu.edu!agate!ames!pacbell.com!well!johnrp
- From: johnrp@well.sf.ca.us (John Panzer)
- Subject: Re: Answers on a postcard...
- Message-ID: <BuEHGr.Kx@well.sf.ca.us>
- Sender: news@well.sf.ca.us
- Organization: Whole Earth 'Lectronic Link
- References: <92254.104002KKEYTE@ESOC.BITNET> <1992Sep10.174914.838@taumet.com>
- Date: Fri, 11 Sep 1992 06:17:15 GMT
- Lines: 33
-
- In article <1992Sep10.174914.838@taumet.com> steve@taumet.com (Steve Clamage) writes:
- >Karl Keyte <KKEYTE@ESOC.BITNET> writes:
-
- (Class X which defines operator,() )
-
- >| X x;
- >| cout << "Value is " << (x=1, x+1) << endl;
-
- (General surprise that order of evaluation of x=1, x+1 is undefined)
-
- >
- >In the expression in parens, it is unspecified whether "x=1" or
- >"x+1" is evaluated first. They are arguments to the "operator,()"
- >function, not the left and right side of a comma-expression. If
- >"x+1" is evaluated first, which is legal, it will use an
- >uninitialized "x.value".
- >
- >Don't write code which depends on unspecified order of evaluation.
- >
- >If there were no "op,()", the "," would mark a comma-expression,
- >and the "x=1" would have to be evaluated first; in that case the
- >whole expression would be well-defined.
-
- Wow. So this means (for example) that if you define && for a class,
- chained && expressions no longer have a defined order of evaluation.
- I subconsciously expected the object to be evaluated first in calls
- like Expr1.operator&&(Expr2). I might even propose this as a new
- constraint, except that there are too many darn proposals already. :^)
-
- John Panzer
- johnrp@well.sf.ca.us
-
-
-