From -6250018466037682242 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!newsfeed00.sul.t-online.de!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: howard.hinnant@gmail.com (Howard Hinnant) Newsgroups: comp.std.c++ Subject: Re: Is this really unspecified behavior? Date: Tue, 20 Dec 2005 05:57:52 GMT Organization: Road Runner Lines: 123 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) 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> <200512161412.jBGECcuC061966@horus.isnic.is> <87bqzfp5t2.fsf@boost-consulting.com> <87r7896z8e.fsf@boost-consulting.com> NNTP-Posting-Host: news.news.demon.net X-Trace: news.demon.co.uk 1135058310 20413 158.152.254.254 (20 Dec 2005 05:58:30 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Tue, 20 Dec 2005 05:58:30 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-User-Agent: MT-NewsWatcher/3.4 (PPC Mac OS X) X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id jBK5vqeL011138; Tue, 20 Dec 2005 16:57:52 +1100 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-NNTP-Posting-Date: Mon, 19 Dec 2005 23:07:45 EST X-Delivered-To: std-c++@ucar.edu X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Newsgroups: comp.std.c++ Xref: g2news1.google.com comp.std.c++:2856 In article <87r7896z8e.fsf@boost-consulting.com>, dave@boost-consulting.com (David Abrahams) wrote: > howard.hinnant@gmail.com (Howard Hinnant) writes: > > > In article <87bqzfp5t2.fsf@boost-consulting.com>, > > dave@boost-consulting.com (David Abrahams) wrote: > > > >> > Smart pointer factory functions in C++0X sound great. Let's have > >> > them (I hope to see your proposal soon). > >> > >> EWG or LWG? > > > > LWG please. If you see core issues also involved (perhaps variadic > > templates, or rvalue reference?), I'll make sure the EWG knows they have > > more motivation for this core issue. Workarounds (if possible) for lack > > of core issues are appreciated. > > Sure, that's easy enough. Ping me after the first week of January, > though, if you *really* want it; it's likely to fall off the radar > otherwise. I've entered it on my calendar. :-) > > evaluate_in_any_order > > { > > auto t1(fancy_component( create_handle() )); > > auto t2(g()); > > [don't use tabs :)] Thanks for the reminder. You caught me (yet again). > > that the world would be significantly safer than it is today > > I'm just not convinced of how significant it is, yet. People will > still be commonly trafficing in unmanaged resources, and we won't have > fixed that. Fair enough. See below... In article <871x098em5.fsf@boost-consulting.com>, dave@boost-consulting.com (David Abrahams) wrote: > 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. Maybe our examples have been too limited. Exposing a bare "new" may not be the only danger. Consider something like: template void X::might_transfer_ownership(std::unique_ptr&& up, int condition1, int condition2) { // ... if (really_want_to_transfer(condition1, condition2) { process(acquire(up), and_process(condition1, condition2)); } // ... } Now on analysis of this member function we decide: 1. If we don't want to transfer ownership, up should keep ownership. 2. If we do want to transfer ownership, then we should take it, even if acquire() fails. The member function acquire(std::unique_ptr& up) servers more than just this use case and is set up to take ownership of up, unless the acquire function itself fails, in which case up retains ownership. However there is also an acquire overload taking a T* which retains ownership of the pointer whether or not acquire fails. We were inspired to this design by std::tr1::shared_ptr --- This is identical to the semantics of std::tr1::shared_ptr constructors: shared_ptr(T* p) always takes ownership of p, even on failure. shared_ptr(auto_ptr& p) only takes ownership from p if the ctor succeeds. So if acquire(up) fails, having up retain ownership is not what we want in this case. The above code is wrong for us. We instead would like: template void X::might_transfer_ownership(std::unique_ptr&& up, int condition1, int condition2) { // ... if (really_want_to_transfer(condition1, condition2) { process(acquire(up.release()), and_process(condition1, condition2)); } // ... } Now, whether or not the acquire fails, we've grabbed ownership of up.get() because we met the conditions that we really wanted to transfer ownership (really_want_to_transfer() evaluated true). This is advanced level code. It has been well designed and well thought through. It has emulated some of our best from tr1 and for good reasons. And yet if and_process() might throw an exception, it is still flawed. No "new" in sight. Careful thought has occurred with respect to resource ownership even under exceptional conditions. The exception safety aspect has even been tested by throwing at every possible point, and inspecting the state. All tests passed. And yet it is still wrong. Imho, if we're still wrong after such careful thought, design and testing, and you can't easily "grep" for this, then C++ has a defect. Maybe you or I or a few other experts could spot the problem in this design. But most people won't. This is scary. -Howard --- [ 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 ]