From 525746319314747551 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!newsgate.cistron.nl!skynet.be!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: usenet-nospam@nmhq.net (Niklas Matthies) Newsgroups: comp.std.c++ Subject: Re: Is this really unspecified behavior? Date: Sat, 10 Dec 2005 04:57:16 GMT Organization: Avonlea Village Improvement Society Lines: 52 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <1132759176.368850.264850@g43g2000cwa.googlegroups.com> <1132933832.802917.153350@g14g2000cwa.googlegroups.com> <1133551647.532929.325730@z14g2000cwz.googlegroups.com> <1133583412.951239.208510@g49g2000cwa.googlegroups.com> <1133910546.716987.80030@g14g2000cwa.googlegroups.com> NNTP-Posting-Host: news.news.demon.net X-Trace: news.demon.co.uk 1134190646 8209 158.152.254.254 (10 Dec 2005 04:57:26 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Sat, 10 Dec 2005 04:57:26 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-User-Agent: slrn/0.9.8.1 (FreeBSD) X-Greylisting: NO DELAY (Relay+Sender autoqualified); processed by UCSD_GL-v2.1 on mailbox7.ucsd.edu; Fri, 09 December 2005 08:49:13 -0800 (PST) X-Orig-X-Trace: individual.net GzlTfhBbWI4uefcWzPQemAE7VPKu9SlLsAZMCTnAEt+RpqbHI= X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-Reply-To: usenet-reply at nmhq dot net X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id jBA4vG7R007576; Sat, 10 Dec 2005 15:57:16 +1100 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-Delivered-To: std-c++@ucar.edu X-Spamscanner: mailbox7.ucsd.edu (v1.6 Aug 4 2005 15:27:38, 0.0/5.0 3.0.4) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Newsgroups: comp.std.c++ X-MailScanner: PASSED (v1.2.8 73131 jB9GnBj8078835 mailbox7.ucsd.edu) Xref: g2news1.google.com comp.std.c++:2726 On 2005-12-09 16:06, Francis Glassborow wrote: > In article , "Andrei Alexandrescu > (See Website For Email)" writes >>(1) A "programmer willing to optimize" who knows that right-to-left >>evaluation is algorithmically better AND knows that left-to-right >>evaluation is guaranteed will introduce named temporary to force >>right-to-left evaluation. That is the best solution of all, better than >>the programmer just leaving optimality at the whim of the compiler. >>It's guaranteed. In contrast, the compiler may or may not detect the >>opportunity by itself so we can't know whether the optimization will be >>done at all. > > I think this is a very good point (that I had not considered > previously). If the programmer knows the default evaluation order s/he > can write code to force a different order. If you do not know the > evaluation order and you believe it matters you have to write code to > enforce your preferred ordering. It might be difficult to know for the programmer which order is more efficient, in particular when the code targets different implementations, or for example with inlined functions where a change in the function's implementation can change the optimal evaluation order of the function arguments at the particular call site. Usually the compiler knows much better than the programmer. But the point is right in that it's the order-independent code that should require special handling by the programmer if necessary, not the order-dependent code. If the order is going to be defined, it would be nice if some language constructs would be provided to mark a group of statements to be executable "in parallel", i.e. having no order dependencies. > However there is more than just order of evaluation, there is the > issue of order of side-effects. Should we go the whole way and force > an ordering on those? Yes, because these cause the actual UB most of the time. Also it would be confusing that (for example) whether os << x++ << x; has predictable behavior depends on whether the type of 'x' is a built-in type or not (i.e. whether '++' is a function call or not). -- Niklas Matthies --- [ 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 ]