From -5405356277122076103 X-Google-Thread: f78e5,174aa7b34b06a51 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.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: SeeWebsiteForEmail@moderncppdesign.com ("Andrei Alexandrescu (See Website For Email)") Newsgroups: comp.std.c++ Subject: Re: Is this really unspecified behavior? Date: Fri, 16 Dec 2005 12:33:20 GMT Organization: Computer Science & Engineering, U of Washington, Seattle Lines: 77 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> <200512131507.jBDF72uC0 "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. If you claim the line above does expose a bald pointer, you have a different definition, our criteria don't compare, end of discussion. If we agree that the code above is sensible, then I claim it is sensible that also an unnamed temporary: auto_ptr(new int) oughtn't leak memory, 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. > 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. > 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. 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 ]