From 5244908734986773157 X-Google-Thread: f78e5,174aa7b34b06a51 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newscon06.news.prodigy.com!prodigy.net!newsfeed-00.mathworks.com!peer-uk.news.demon.net!kibo.news.demon.net!mutlu.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: hyrosen@mail.com (Hyman Rosen) Newsgroups: comp.std.c++ Subject: Re: Is this really unspecified behavior? Date: Tue, 29 Nov 2005 15:11:58 GMT Lines: 37 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <200511291438.jATEcauC061819@horus.isnic.is> References: <1132629737.664847.151630@o13g2000cwo.googlegroups.com> <1132722639.345095.296070@f14g2000cwb.googlegroups.com> <200511231401.jANE1BuC092897@horus.isnic.is> <37hco1hvfg2s43q2dv3003her7im99airg@4ax.com> <1twif.776$iZ3.758@trndny03> NNTP-Posting-Host: news.news.demon.net Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: news.demon.co.uk 1133277123 28227 158.152.254.254 (29 Nov 2005 15:12:03 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Tue, 29 Nov 2005 15:12:03 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id jATFBwDH014123; Wed, 30 Nov 2005 02:11:58 +1100 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-Delivered-To: std-c++@ucar.edu X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Newsgroups: comp.std.c++ Xref: g2news1.google.com comp.std.c++:2625 David Abrahams wrote: > Consistency with what? The past. The argument that we are so tied to backward compatibility that we may not even specify what was formerly unspecified. > Is it implausible to you that detecting the cases where expressions > must not be reordered would add complexity to an already gnarly area > in any good compiler? Yes, very implausible. After all, optimizers do deal with improving code over multiple statements, and in that case evaluation order is defined. Any compiler text which speaks about optimization describes various analyses used to determine when statements can be moved around. It's very nearly fundamental to what optimizers do. > no respect for the committee This has nothing to do with respect. One argument against specifying evaluation order is that the committee is reluctant to break implementations (see "consistency" above). But it's clear that the standardization process in fact broke implementations across the board in dozens of ways, and many of those implementations still haven't caught up. That's not a bad thing, that's a good thing. It demonstrates that the committee is willing to break implementations for a good cause, and that should be true as well for evaluation order. --- [ 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 ]