From -1423133797238215439 X-Google-Thread: f78e5,174aa7b34b06a51 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!news3.google.com!news2.volia.net!newsfeed01.sul.t-online.de!t-online.de!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: Fri, 25 Nov 2005 01:03:27 GMT Lines: 105 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <37hco1hvfg2s43q2dv3003her7im99airg@4ax.com> 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 1132880616 11228 158.152.254.254 (25 Nov 2005 01:03:36 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Fri, 25 Nov 2005 01:03:36 +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 jAP13UhE006813 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 jAP13RTs006778; Fri, 25 Nov 2005 12:03:27 +1100 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-NNTP-Posting-Date: Thu, 24 Nov 2005 17:20:15 -0600 X-Delivered-To: std-c++@ucar.edu X-TN-Interface: 209.99.127.21 X-Postfilter: 1.3.32 X-Authentication-Warning: serv1.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++:2595 On Thu, 24 Nov 2005 04:40:36 GMT, eldiener_no_spam_here@earthlink.net (Edward Diener No Spam) 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's not exaggerating that much. In my experience at least, the great majority of programmers aren't aware of the (lack of) rules, and the minority who do understand the rules still tend to forget them occasionally. I know it bites me every so often. >> It's asinine not >> to have a defined order of evaluation, including side effects. > >I totally agree with you here. 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. 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. I don't think you'd get as much push-back from Bjarne as you think. :-) Evalution reordering is a well-known source of difficulty for programmers and it has been raised about every other month for at least two decades. But the reason why it isn't fixed in C++ (or C) has nothing to do with C compatibility. The real reason is performance: When you talk about nailin= g down the order of evaluation, the first howls of protest usually come fro= m the people who write code optimizers and who demand to know why on earth you want to tie their hands like this and turn off optimization opportunities they want to exploit. BTW, there's a direct parallel (pardon the pun) between this issue and 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 (to simplify a little, this means among other things that th= e chip doesn't get the flexibility to reorder memory reads or writes and must follow exactly what's in the source code) is nice, but nobody actually ships it because it is believed to be too slow for practical use. This is part of what I had in mind when I wrote: 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 evaluation reordering falls into the same category as read reorder, 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. -- "The Free Lunch Is Over" http://www.gotw.ca/publications/concurrency-ddj.htm Have a nice day, 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 ]