From -8301758420258025219 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!border2.nntp.dca.giganews.com!nntp.giganews.com!newspeer1.nwr.nac.net!colt.net!news-lond.gip.net!news.gsl.net!gip.net!newsfeed.icl.net!newsfeed.fjserv.net!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: dave@boost-consulting.com (David Abrahams) Newsgroups: comp.std.c++ Subject: Re: Is this really unspecified behavior? Date: Tue, 20 Dec 2005 03:02:24 GMT Lines: 96 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <871x098em5.fsf@boost-consulting.com> 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> NNTP-Posting-Host: news.news.demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: news.demon.co.uk 1135047755 10340 158.152.254.254 (20 Dec 2005 03:02:35 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Tue, 20 Dec 2005 03:02:35 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) X-DMCA-Complaints-To: abuse@rcn.net X-Greylisting: NO DELAY (Relay+Sender autoqualified); processed by UCSD_GL-v2.1 on mailbox8.ucsd.edu; Mon, 19 December 2005 04:18:23 -0800 (PST) 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-Cancel-Lock: sha1:+vO/TTQD8QHNL/gT71URvUfsS00= X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id jBK32OYM029839; Tue, 20 Dec 2005 14:02:24 +1100 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-NNTP-Posting-Date: Mon, 19 Dec 2005 06:18:19 -0600 X-Delivered-To: std-c++@ucar.edu X-Spamscanner: mailbox8.ucsd.edu (v1.6 Aug 4 2005 15:27:38, 0.0/5.0 3.0.4) X-Postfilter: 1.3.32 X-Authentication-Warning: serv1.gc.dca.giganews.com: news set sender to poster@giganews.com using -f X-Newsgroups: comp.std.c++ X-MailScanner: PASSED (v1.2.8 24178 jBJCIKSa032286 mailbox8.ucsd.edu) Xref: g2news1.google.com comp.std.c++:2838 SeeWebsiteForEmail@moderncppdesign.com ("Andrei Alexandrescu (See Website For Email)") writes: > David Abrahams wrote: >> "Andrei Alexandrescu (See Website For Email)" writes: >> >>>David Abrahams wrote: >>> >>> >>>>It doesn't look safe to me. It's a complicated expression involving a >>>>bare unmanaged resource. Forget for a moment that you already know a >>>>lot about auto_ptr. The general case is something like: >>>> f( fancy_component( create_handle() ), g() ); >>>>There's a lot going on in that line. >>> >>>Yah, but there's a lot going on in this line, too: >>> >>>f( fancier_component( fancy_component( create_handle() ) ); >>> >>>which is safer than the safest vault in the safest Swiss bank. >> ?? You don't know that at all! What happens in fancy_component? >> Is it designed to take ownership of a bare handle immediately, or only >> if it doesn't throw? Not to mention that fancy_component might not take ownership of the handle at all. > That makes all the difference. > > The important part is that it has the choice. What choice, please? Why should doing the right thing with deallocation be up to fancy_component and some agreement between its implementation and the caller? If I use new_ >() then *I'm* taking responsibility for making sure that the pointer is always managed, regardless of where it's passed. By the way, we can write the above (for some reasonable number of arguments, say, 5) today. > Compare that with your example. Which one, please? > 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. 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. >>>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'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.? 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. 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. -- Dave Abrahams Boost Consulting www.boost-consulting.com --- [ 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 ]