From 8883851091786260018 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!newscon06.news.prodigy.com!prodigy.net!newsfeed-00.mathworks.com!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: Sun, 18 Dec 2005 01:20:51 GMT Lines: 76 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: <87bqzfp5t2.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> <200512161412.jBGECcuC061966@horus.isnic.is> NNTP-Posting-Host: news.news.demon.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: news.demon.co.uk 1134868908 15574 158.152.254.254 (18 Dec 2005 01:21:48 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Sun, 18 Dec 2005 01:21:48 +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-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:NVp74q2nuLhf2y9vwe9jhVnRag0= X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id jBI1Kp9c024538; Sun, 18 Dec 2005 12:20:51 +1100 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-NNTP-Posting-Date: Sat, 17 Dec 2005 19:11:56 -0600 X-Delivered-To: std-c++@ucar.edu X-TN-Interface: 209.99.127.23 X-Postfilter: 1.3.32 X-Authentication-Warning: serv3.gc.dca.giganews.com: news set sender to poster@giganews.com using -f X-Newsgroups: comp.std.c++ Xref: g2news1.google.com comp.std.c++:2811 howard.hinnant@gmail.com (Howard Hinnant) writes: > In article , > dave@boost-consulting.com (David Abrahams) wrote: > >> > The problem with the current language definition >> > is that the compiler has too much freedom to reorder >> > expressions, and that leads to unsafe code. >> >> I disagree. The handling of bare unmanaged resources is a more >> fundamental reason for the leakage problem. It's easy to prove that: >> if you add evaluation ordering, you are still left with many other >> cases where handling unmanaged resources leads to the same kind of >> leakage problem. However, if you take away the use of unmanaged >> resources, the leakage problem goes away completely. > > I suspect we all agree that handling unmanaged resources is risky. But > the problem is that: > > f(auto_ptr(new T), g()); > > looks *very much* like code that is only handling managed resources. > Joe Coder is going to look at that and say : Good job! You're safely > handling your resources! > > Banning "new T" in C++0X isn't an option. No, of course it isn't. But neither is it an option to ban many other dangerous, but ocassionally necessary, constructs. We could very easily make "new T" something that is hardly ever to be used directly in "good code," just like, say, "new (p) T" and "~T", and, for that matter, "delete p" are today. IMO "new T" should be red flag in code reviews. > Smart pointer factory functions in C++0X sound great. Let's have > them (I hope to see your proposal soon). EWG or LWG? > But that's only a partial solution. We also very much need this to > be as safe as it looks: > > f(auto_ptr(new T), g()); Why? More importantly, why does that look safe to you? 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. > And to get to that point, mandating left-to-right, or right-to-left is > overkill. We only need to mandate that there is a sequence point > between the argument evaluations. And my point is that it's not the best way to solve the biggest problem it purports to solve (leaks). It's not even a complete solution to that problem. It's a big hammer that only hits the edge of the nail head. I'm not sure if it bends the nail or drives it in partway, but it makes me nervous. My thumb is nearby ;-) -- 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 ]