From 6678302192349802834 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,7522e5259f7267d6 X-Google-Attributes: gidf78e5,public From: Ron Natalie Subject: Re: x = y = z; Undefined? Date: 2000/01/11 Message-ID: <387B6338.FCE9D984@sensor.com>#1/1 X-Deja-AN: 571266584 X-NNTP-Posting-Host: 156.40.240.200 Content-Transfer-Encoding: 7bit Approved: stephen.clamage@sun.com (comp.std.c++) References: <3876254a.30903561@news.csrlink.net> <3879ca08.3142429@news.csrlink.net> <387b3c32.7816532@news.csrlink.net> To: John Potter X-Accept-Language: en X-UID: 0000000001 X-Status: $$$T Content-Type: text/plain; charset=x-user-defined Organization: Sensor Systems Mime-Version: 1.0 Newsgroups: comp.std.c++ Originator: clamage@taumet John Potter wrote: > > I disagree. The standard requires that expressions be evaluated as > written. Where does it say that (hint: it doesn't, absent sequence points, the order of evaluation is UNSPECIFIED). > > : One could concieve a compiler that would decide 'ok, the final > : destination is i1' and then add three too it. Then manage the assign > : i1=i2 after it. Since there can be no more than one assignment to a > : single variable in a sequencing point, there's nothing wrong with this > : implementation, either. > > No. The compiler could compute the value 5 store it in i1 and then > store the value 2 from i2 in i1. It might even store the & or | of > those two values. Adding 3 to the old value of i1 is not present > in the expression. Sorry, this is wrong. The order of evaluation is not specified in C++ absent sequence points. The original poster is correct. Changing il twice between sequence points is wrong. > > You seem to interpret undefined behavior as a license for the compiler > to do stupid things. I interpret it as a license to do reasonable > things on the assumption that there is no undefined behavior without > needing to verify that. Any compiler that does anything based upon > detecting undefined behavior better be issuing a diagnostic. No. UNDEFINED BEHAVIOR does not require a diagnostic. There are far too many things that are undefined behavior that it are impossible to check for at compile time. By the standard saying it's undefined behavior it says the compiler doesn't need to consider handling this sort of error. > > Consider: > int a[] = { 11, 13 }, i2(2), i3(3); > int& i1(a[0]); > int* p; > *((p = &(i1 = i2)) + 1) += i3; > > There is no undefined behavior and a[] == { 2, 16 }. This is a different case. a[0] is stored once, a[1] is stored once. The falue of a[0] is not used for anything other than the target of the store, nore is a[1]. > An interesting point is that in this part of the standard (5) where it > talks about undefined behavior, the examples label it as unspecified > behavior. I assume that the normative makes the non-normative examples > errors. > As it stands, it's undefined behavior. Even if it were unspecified behavior it still would not yield the predictable results that you claim. [ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]