From 4822876729466937270 X-Google-Thread: f78e5,174aa7b34b06a51 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!news.alt.net!comp-std-cpp-robomod!not-for-mail From: "Bob Bell" Newsgroups: comp.std.c++ Subject: Re: Is this really unspecified behavior? Date: Wed, 14 Dec 2005 22:10:27 CST Organization: http://groups.google.com Lines: 61 Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <1134618172.828330.119520@g14g2000cwa.googlegroups.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> <200512131507.jBDF72uC006630@horus.isnic.is> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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-Trace: posting.google.com 1134618178 18330 127.0.0.1 (15 Dec 2005 03:42:58 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 15 Dec 2005 03:42:58 +0000 (UTC) User-Agent: G2/0.2 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050923 CentOS/1.0.7-1.4.1.centos4 Firefox/1.0.7,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: g14g2000cwa.googlegroups.com; posting-host=160.33.20.84; posting-account=YkQmFgwAAADb4VCQxbKct8M2us8SA5QU X-Virus-Scanned: amavisd-new at ucar.edu X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Xref: g2news1.google.com comp.std.c++:2774 Hyman Rosen wrote: > David Abrahams wrote: > > f doesn't have an auto_ptr parameter. It takes two pointers. > > > > It's not about "having to" change. It's about whether you'll notice > > that the change affects safety. > > I'm still confused. If I write > T *p = new T; g(); > or > g(); T *p = new T; > then in the first case I'll leak memory if g() throws, > and in the second case I won't. But what does this have > to do with safety? It's not just a memory leak; it's an object that isn't destroyed. If the destructor has important side-effects, then it could be a big problem. > Obviously, if I use raw pointers then > my code is subject to resource leaks from exceptions that > happen afterwards. > > The point is that with a properly specified order of > evaluation, code which tries to be safe really can be > safe, as opposed to the f(auto_ptr, auto_ptr) mess that > we have now. It strikes me that the phrase "code which tries to be safe really can be safe" applies to the situation today as well. Here's some code that "tries to be safe" today: std::auto_ptr p1(new int(0)); std::auto_ptr p2(new int(0)); function_taking_two_auto_ptrs(p1, p2); > Code that doesn't try to be safe is going > to get only slightly safer, in that it won't be subject > to the compiler's arbitrary reorderings, but latent > resource leaks aren't going to go away by themselves. To me, this sounds like "code that doesn't try to be safe won't be safe", which again sounds like the situation we have today. The advantage of well-defined order of evaluation is that it may make it simpler to reason about what happens when, but Dave's example shows that it won't eliminate safety gotchas from expression evaluation. For the record, I'm not taking a position one way or the other on whether order of evaluation should be nailed down. I'm comfortable with things the way they are, but I think this has been an interesting discussion. Bob --- [ 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 ]