From 5408581926478774107 X-Google-Thread: f78e5,174aa7b34b06a51 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!news-lei1.dfn.de!news-fra1.dfn.de!newsfeed.hanau.net!newsfeed.vmunix.org!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: hsutter@gotw.ca (Herb Sutter) Newsgroups: comp.std.c++ Subject: Re: Is this really unspecified behavior? Date: Sat, 26 Nov 2005 01:12:33 GMT Lines: 177 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <1132629737.664847.151630@o13g2000cwo.googlegroups.com> <1132722639.345095.296070@f14g2000cwb.googlegroups.com> <200511231401.jANE1BuC092897@horus.isnic.is> NNTP-Posting-Host: news.news.demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: news.demon.co.uk 1132967586 16283 158.152.254.254 (26 Nov 2005 01:13:06 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Sat, 26 Nov 2005 01:13:06 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-MIME-Autoconverted: from 8bit to quoted-printable by mulga.cs.mu.OZ.AU id jAQ1CphE016768 X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id jAQ1CX1U016499; Sat, 26 Nov 2005 12:12:33 +1100 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-NNTP-Posting-Date: Fri, 25 Nov 2005 17:56:26 -0600 X-Delivered-To: std-c++@ucar.edu X-TN-Interface: 209.99.127.20 X-Postfilter: 1.3.32 X-Authentication-Warning: serv3.gc.dca.giganews.com: news set sender to poster@giganews.com using -f X-Newsreader: Forte Agent 1.8/32.548 X-Newsgroups: comp.std.c++ Xref: g2news1.google.com comp.std.c++:2603 [I sent a partial version of this message too soon. This is the complete version.] There are to interrelated issues on this thread, and I'll try to address both of them. They are: 1. sequence points 2. (lack of) rules on order of evaluation of function arguments Both issues are around leaving the implementation latitude to reorder work, and the tradeoff is between leaving the rules loose so that optimizers can generate better code and tightening the rules so that programmers have less of a burden to understand their programs. I'll show below that exactly the same tradeoff comes in a third related case of reordering not yet mentioned in this thread: 3. instruction reordering, especially memory read/write reordering Note that #3 is of very current interest because memory access ordering guarantees are a key part of the C++0x memory model for concurrency now under development. Coming in after Hyman and Edward, who were talking first about issue #1: Edward Diener wrote: >Hyman Rosen wrote: >> Greg Herlihy wrote: >>> Essentally, the result of evaluating i =3D v[i++] is unspecified beca= use >>> i's value is accessed only once. >>=20 >> No, it's undefined in the built-in case, because i is modified >> twice in the same expression (by the increment and by the >> assignment) without an intervening sequence point. >>=20 >> Once again, I invite everyone in the newsgroup to notice how >> no one understands the rules as they exist. > >Obviously not true except as hyperbole. Hyman is not exaggerating at all. There is perhaps no greater point of misunderstanding of C than sequence points. Virtually all C++ experts, including C++ committee members and including myself until the last Santa Cruz meeting in fall 2002, think they understand sequence points. We typically view them as an unfortunate and complicated wart we inherited from C, but one that is at least well understood in the C committee. That is not true. My eyes were opened when I attended the fall 2002 C meeting, and saw a detailed presentation of one person's theory of how sequence points probably work, how they probably should work, and what we're still not sure about. It was a revelation to me to learn that this was only the mos= t recent part of an ongoing series of discussions and debates within the C committee about what exactly sequence points are, how they actually work, and how they should work. Even if you know all the detailed reasons why "= i =3D i++;" is indeterminate, nobody should assume that the way C90 or C99 sequence points are specified is either well understood or that implementations are consistent in the details. Now we segue over to the related issue #2 of order of evaluation of function arguments: >> It's asinine not >> to have a defined order of evaluation, including side effects. > >I totally agree with you here.=20 Me too. In my experience at least, most C/C++ programmers aren't aware of the (lack of) rules around evaluation ordering, and the minority who do understand the rules still tend to forget them occasionally. I know it bites me every so often. >With all due respect to Mr. Stroustrup's=20 >printed opinion about the importance of C++ maintaining compatibility=20 >with the C language, I also feel that at some time in the future, and I=20 >hope it is the near future, C++ should stop trying to maintain=20 >compatibility with the C language and do the right things as far as its=20 >own C++ language specification is concerned.=20 Aside: I don't think you'd get as much push-back from Bjarne as you think. :-) >This is just one of many=20 >other areas, which have been mentioned in numerous other posts on these=20 >NGs, where compatibility with the C language is holding C++ back from=20 >advancing as a language of its own. Not exactly. Both sequence points and evalution reordering are a well-known sources of difficulty for programmers, and these issues have been raised about every other month for as long as C++ and C have existed. But the reason for these relaxed rules, and why they aren't nailed down i= n C++ (or C), actually has nothing to do with C compatibility or ineptitude or any of the other usual suspects. The real reason why C and C++ have this latitude is for performance. When you talk about nailing down the order of evaluation, the first howls of protest come, not from language designers or compiler front-end writers (who would be only too happy to oblige, because who likes having flaky corner cases?), but from the people who write code optimizers and who demand to know 'why on earth you want to tie our hands like this and turn off optimization opportunities we want to exploit for you -- do you _really_ want your code to run slow?' There is a direct relationship between these two issues and issues #3: th= e issue of instruction reordering, especially memory read/write reordering, anywhere in the tool/hardware chain right down to the processor itself. It's common wisdom in the hardware world that a sequentially consistent memory model is nice (to simplify a little, SC means that the hardware must not reorder memory reads or writes and must follow exactly what's in the source code), but nobody actually ships that because it is believed t= o be too slow for practical use. It's quite a revelation to most people doing lock-free concurrent programming for the first time that the memory reads and writes they put into their code might not be respected at all, if the processor (or the optimizer, or any other part of the chain) decides it would rather do things in a different order than you asked for= , so sorry. This is part of what I had in mind when I wrote (in "The Free Lunch Is Over," http://www.gotw.ca/publications/concurrency-ddj.htm): Chip designers are under so much pressure to deliver ever-faster CPUs that they=92ll risk changing the meaning of your program, and possibly break it, in order to make it run faster And: Two noteworthy examples in this respect are write reordering and read reordering: Allowing a processor to reorder write operations has consequences that are so surprising, and break so many programmer expectations, that the feature generally has to be turned off because it=92s too difficult for programmers to reason correctly about the meaning of their programs in the presence of arbitrary write reordering. Reordering read operations can also yield surprising visible effects, but that is more commonly left enabled anyway because it isn=92t quite as hard on programmers, Note that the latitude around sequence points and evaluation reordering falls into the same category as read reordering, including this final comment: and the demands for performance cause designers of operating systems and operating environments to compromise and choose models that place a greater burden on programmers because that is viewed as a lesser evil than giving up the optimization opportunities. That's why we have at least some read reordering in nearly all memory models now in production, why we have argument evaluation reordering, and why we have the latitude around sequence points in all its inglory. It is believed to be necessary. No, I can't point to measurements, but I'm sure someone can and I would be interested to see real data about how much nailing each of these down would cost for standard optimizers on various popular architectures (alas, that's fairly hard to measure). Herb --- Herb Sutter (www.gotw.ca) (www.pluralsight.com/blogs/hsutter) Convener, ISO WG21 (C++ standards committee) (www.gotw.ca/iso) Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj) Architect, Developer Division, Microsoft (www.gotw.ca/microsoft) --- [ 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 ]