From 6084761162627203072 X-Google-Thread: f78e5,174aa7b34b06a51 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!fr.ip.ndsoftware.net!skynet.be!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: ark@acm.org ("Andrew Koenig") Newsgroups: comp.std.c++ Subject: Re: Is this really unspecified behavior? Date: Thu, 8 Dec 2005 07:00:42 GMT Organization: AT&T Worldnet Lines: 38 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <5PDlf.240414$zb5.171520@bgtnsc04-news.ops.worldnet.att.net> References: <1132629737.664847.151630@o13g2000cwo.googlegroups.com> <1132662585.882464.24110@f14g2000cwb.googlegroups.com> <1132759176.368850.264850@g43g2000cwa.googlegroups.com> <1132933832.802917.153350@g14g2000cwa.googlegroups.com> <1133551647.532929.325730@z14g2000cwz.googlegroups.com> <1133583412.951239.208510@g49g2000cwa.googlegroups.com> <200512071313.jB7DDUuC077731@horus.isnic.is> NNTP-Posting-Host: news.news.demon.net X-Trace: news.demon.co.uk 1134025248 2718 158.152.254.254 (8 Dec 2005 07:00:48 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Thu, 8 Dec 2005 07:00:48 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Priority: 3 X-Greylisting: NO DELAY (Relay+Sender autoqualified); processed by UCSD_GL-v2.1 on mailbox8.ucsd.edu; Wed, 07 December 2005 08:09:43 -0800 (PST) X-RFC2646: Format=Flowed; Response X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-MSMail-Priority: Normal X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id jB870gJk011629; Thu, 8 Dec 2005 18:00:42 +1100 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-NNTP-Posting-Date: Wed, 07 Dec 2005 16:09:37 GMT X-Delivered-To: std-c++@ucar.edu X-Spamscanner: mailbox8.ucsd.edu (v1.6 Aug 4 2005 15:27:38, 1.2/5.0 3.0.4) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Newsreader: Microsoft Outlook Express 6.00.2900.2670 X-Newsgroups: comp.std.c++ X-MailScanner: PASSED (v1.2.8 48608 jB7G9cS1060191 mailbox8.ucsd.edu) Xref: g2news1.google.com comp.std.c++:2695 "Hyman Rosen" wrote in message news:200512071313.jB7DDUuC077731@horus.isnic.is... > Well, that's what I said. But often compilers actually have a > fixed order of evaluation, it's just that they don't tell anyone > what it is, and it's subject to change between versions or vendors. > So order dependencies might creep in and accidentally work, until > something changes. I haven't done a survey of compilers, but I have certainly encountered compilers that do not have a fixed order of evaluation in the sense in which I think you mean it. It is certainly true that most compilers will evaluate a given expression in the same order every time they encounter it (assuming that the types are the same), but that doesn't imply a fixed order of evaluation. Here's why. One common code-generation technique is to try to minimize the total number of registers or temporary locations needed to evaluate an expression. One well-known algorithm for doing that is that whenever there is an operator with operands that can be evaluated in either order, the compiler should try to evaluate first the operand that requires the most registers. A compiler that uses such an algorithm might well compile f()+g(x,y) by evaluating g(x,y) first, then f(), then computing the sum, but nevertheless might compile h()+f()+g(x,y) by evaluating h(), then f(), and finally g(x,y). This would happen if the subexpression h()+f() required more registers to evaluate than the subexpression g(x,y). I would expect this kind of behavior to be common, especially among optimizing compilers. --- [ 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 ]