From 3586406074594008000 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: Fri, 16 Dec 2005 22:20:08 -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) Delivered-To: std-c++@ucar.edu X-Authentication-Warning: serv3.gc.dca.giganews.com: news set sender to poster@giganews.com using -f From: David Abrahams Subject: Re: Is this really unspecified behavior? 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> <200512131507.jBDF72uC0 Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (windows-nt) Cancel-Lock: sha1:Bov8ymeaJIduEwZRzE7XRS7yS5s= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@rcn.net X-DMCA-Complaints-To: abuse@rcn.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 Newsgroups: comp.std.c++ X-Greylisting: NO DELAY (Relay+Sender autoqualified); processed by UCSD_GL-v2.1 on mailbox8.ucsd.edu; Fri, 16 December 2005 15:03:07 -0800 (PST) X-Spamscanner: mailbox8.ucsd.edu (v1.6 Aug 4 2005 15:27:38, 0.0/5.0 3.0.4) X-MailScanner: PASSED (v1.2.8 38030 jBGN34dR049622 mailbox8.ucsd.edu) X-Virus-Scanned: amavisd-new at ucar.edu X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Approved: Fergus Henderson , moderator of comp.std.c++ X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Date: Fri, 16 Dec 2005 22:17:59 CST Lines: 122 NNTP-Posting-Host: 65.182.171.162 X-Trace: sv3-iyi6XkcSTKgA+20+YsSXPtaR92z8kBgtjfFi1A8liLDfMgqToDFv/CGiBZihyF6ThVz9lxg14gUfAu4!Jsv5AVrTK5HJzRcmiPNkNnOlTa8xa106wMzH0Oa89WnyFbOPn9pRlwsCv81s3lZ0//IckiPsEy4V!fjTaZ6J9hYhPppauWw== 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++:2798 SeeWebsiteForEmail@moderncppdesign.com ("Andrei Alexandrescu (See Website For Email)") writes: > David Abrahams wrote: >> "Andrei Alexandrescu (See Website For Email)" writes: >>> Hmmm... I think Hyman had a different definition of "code that >>> tries to be safe". The meaning would be "code that doesn't >>> manipulate at any moment bald pointers". You see, the thing is that >>> the code >>> >>> function_taking_two_auto_ptrs(auto_ptr(new int), >>> auto_ptr(new int)) >>> >>> does not expose at any moment any bald pointer, >> Of course new int >> exposes a bald pointer. That's *precisely* the root cause of the >> problem. That should be encapsulated in >> new_ >() >> It's even less typing. > > Well I guess it depends on how we define "expose". For example, I > believe the code below doesn't: > > auto_ptr sp(new int); > > The programmer calls new to create a temporary pointer that's > immediately passed to a class that manages it. No stars in sight, no > trouble, end of story. It's not the presence of stars in the code that causes the problem. struct might_throw { might_throw(int*) throw(std::exception); }; int f(might_throw); int x = f(new int); > If you claim the line above does expose a bald pointer, I do. > you have a different definition, our criteria don't compare, end of > discussion. So we can't discuss the validity of your criteria? > If we agree that the code above is sensible, It's sensible, because it works. And it works because of what you know about the definition of auto_ptr. > then I claim it is sensible that also an unnamed temporary: > > auto_ptr(new int) > > oughtn't leak memory, Sensible, yes. But if people stop initializing auto_ptr with bare pointers, it's a non-issue. > and I'd also claim that it's exactly because of > unspecified order of evaluation of funtion arguments that: > > extern f(auto_ptr, auto_ptr); > f(auto_ptr(new int), auto_ptr(new int)); > > might leak. There's no other context in which the leak is possible > that I can imagine. Which leak? Leaks are obviously possible in other contexts. I don't understand how to tell whether any of those are "the leak." Anyway, I'd rather cure the fundamental leaking problem than fix order of evaluation, which I deem to be less important. >> So you seem to be starting with the axiom that >> foo( auto_ptr( new T ), auto_ptr( new T ) ) >> isn't "unsafe at any moment." But of course it is completely unsafe >> or we wouldn't be having this discussion. And you find that to >> conflict with your axiom. So that line of reasoning seems circular to >> me. > > I'm starting simply with the desideratum that said line *oughtn't be* > unsafe at any moment. I desire that because there are no other contexts > in which auto_ptr( new T ) could leak. Is this a different context? template int f( T x, int* y = new int); int x = f( auto_ptr( new T ) ); >> All that said, I can see an argument for your position. I think >> you'd like exception-safety to be "context free," so that if >> expression1 and expression2 are each exception-safe, then some >> expression3 composed of expression1 and expression2 is also >> exception-safe. > > That sounds like a very nice formalization of a worthy goal. And I > believe that function argument evaluation is the only instance where > that goal is unrealized. Oh, maybe that's what you mean by context. What about this? *auto_ptr( new int ) + *auto_ptr( new int ); -- 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 ]