From -4145104779810802192 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!local01.nntp.dca.giganews.com!nntp.speakeasy.net!news.speakeasy.net.POSTED!not-for-mail NNTP-Posting-Date: Tue, 20 Dec 2005 00:00:01 -0600 Return-Path: X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) Newsgroups: comp.std.c++ From: "Andrei Alexandrescu (See Website For Email)" Subject: Re: Is this really unspecified behavior? Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050716 Thunderbird/1.0.6 Mnenhy/0.7.2.0 Content-Transfer-Encoding: 7bit Organization: Computer Science & Engineering, U of Washington, Seattle 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> <0l5ep1ppfhdj5p1pcu7e4na4ub0vjajlq3@4ax.com> <87oe3e8e0c.fsf@boost-consulting.com> <871x098em5.fsf@boost-consulting.com> Mime-Version: 1.0 X-Nntp-Posting-Host: parakeet.ee.washington.edu Approved: Fergus Henderson , moderator of comp.std.c++ X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Date: Mon, 19 Dec 2005 23:58:37 CST Lines: 137 NNTP-Posting-Host: 65.182.171.162 X-Trace: sv3-Cq4VQJn+G6k9sOV08c60NPEYJ+CSuGpXnLeDStXeFHH/CGl7gtKD+HDl64gi9mALW29x0cMxxHsMJV3!jyHhiNKnFGDSWyqpbup1SQV+yrv/k20E5qlh3riFFdJilt4jskwCffl2qlAXGj/hl8NDyNjPp5Xi!dGSFwYCb6i15reqRf3w= X-Complaints-To: abuse@speakeasy.net X-DMCA-Complaints-To: abuse@speakeasy.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news1.google.com comp.std.c++:2854 David Abrahams wrote: > SeeWebsiteForEmail@moderncppdesign.com ("Andrei Alexandrescu (See Website For Email)") writes: > > Not to mention that fancy_component might not take ownership of the > handle at all. It doesn't matter. That answer is entirely missing my point. >>That makes all the difference. >> >>The important part is that it has the choice. > > > What choice, please? It's simple. You said that: // Example 1 f( fancy_component( create_handle() ), g() ); does not look safe to you because "there's a lot going on in that line". To reveal that "a lot going on" is not the reason for which the line above is unsafe, and to also reveal that it's exactly the unspecified order of evaluation that's the culprit, I replied that: // Example 2 f( fancier_component( fancy_component( create_handle() ) ); is safe although "there's a lot going on in that line", too. Now allow me to explain things a bit in an attempt to clear any past or future misunderstanding. Example 1 is unsafe because no matter how programmers are implementing the functions, it could leak. Example 2 is safe if the functions are properly implemented and respect each other's contract. So while Example 1 is rotten by definition without even looking past that one line of code, Example 2 is valid, provided of course the call sequence makes sense. That's why I was saying that the code in Example 2 "has a choice" of being correct. I think it's super clear now that the only problem is with the unspecified order of evaluation. >>Compare that with your example. > > Which one, please? Example 2 with Example 1 above. >>And, no comment to my other examples? > > > They all look the same to me: they all do a bare "new" and thus expose > the user to handling a raw pointer at some point or other. Yet they don't suffer of leaks. I thought I made my point very clear: I showed a number of examples that are safe, yet are very similar to the unsafe example. > Just as > you'd like an expression to be safely usable in any context if it can > be used safely alone, I'd like all expressions in common use to be > safe regardless of the context they're placed in. "new T" is not like > that: you'd better be really careful where and how you do it. > Mandating evaluation order will only go a small distance toward fixing > that problem. Fine. I'd also add, mandating new_ > will only go a small distance toward fixing the problems created by leaving the execution order unspecfied :o). >>>>Leaks are not the biggest problem of unspecified defined order of >>>>evaluation. They are a pretty good showcase, though. >>> >>>What's the biggest problem? >> >>Their being a gratuitous source of bugs, incompatibilities, and >>nonportability. > > > What kind of bugs and incompatibilities do you get that make this a > big problem? I don't, because I've learned my lesson the hard way. Why should it be the same for others? Bugs appear because code seems to work under certain conditions when evaluation is made out of order. Incompatibilities appear when some code works with a compiler but not with another. > I'm very suspicious of any crusade to eliminate all low-level > differences between compilers. Smells like -- no offense intended; > I'm just identifying where my reaction comes from -- Java hype to me. > Do you also want to mandate standard sizes for short, int, long, etc.? I'm very suspicious of any crusade to maintain the status quo at all costs :o). I only think it's very healthy to revisit assumptions that might have been invalidated by progress in compiler technology and hardware. I believe that the assumption that leaving order of evaluation unspecified improves performance has been well rendered anachronic. > That said, I'm not closed-minded about this; I just need to be > convinced ;-) So far it seems like something we *could* do, that would > render existing compilers nonconforming in a fundamental way, create > backward compatibility problems, break existing (nonportable) code, > and consume valuable core language drafting time. Well it's not that bad. Existing compilers will work for existing code. Existing standard-conforming code must not depend on the order of evaluation. Ergo, order of evaluation doesn't matter for existing standard code. Ergo, old compilers can compile old code no problem. > I'm just not > convinced the benefits justify the costs yet, especially when the > biggest problems *I've* seen identified so far can be solved more > completely with a library and (IMO painless) changes to common > programming practice. I think the practice of playing covered is worthwhile, but I don't think the f(auto_ptr, auto_ptr) is the biggest. It just happens to be particularly glaring :o). Andrei --- [ 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 ]