From 8374460544195658105 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,df06663c0326d841 X-Google-Attributes: gidf78e5,public X-Google-Thread: 109fba,df06663c0326d841 X-Google-Attributes: gid109fba,public From: sirwillard@my-dejanews.com Subject: Re: auto_ptr copy semantics Date: 1999/05/26 Message-ID: <7if3ih$frk$1@nnrp1.deja.com> X-Deja-AN: 482310265 Approved: Valentin Bonnard References: <7el5br$kjj$1@nnrp1.dejanews.com> <7f0i8a$sc9$1@nnrp1.dejanews.com> <7f5bhs$vgm$1@nnrp1.dejanews.com> <7gvibk$tkl$1@nnrp1.deja.com> <7h4q93$ptn$1@nnrp1.deja.com> X-Original-Date: Tue, 25 May 1999 21:09:38 GMT X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT) X-Http-Proxy: 1.1 x42.deja.com:80 (Squid/1.1.22) for client 167.16.119.20 Organization: Deja.com - Share what you know. Learn what you don't. X-Article-Creation-Date: Tue May 25 21:09:38 1999 GMT X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBVAwUAN0v4QawEuYhIxRhxAQF98wH+KqrGfLPzat6jRXNZiqbzHhjHCGX9t6E/ MX87xGedaMr8aKHRNeNPwGPNR+Y9MBzaO4RmY3iTUUxYdxkh+gARvA== =Km55 Newsgroups: comp.lang.c++,comp.std.c++ In article , "Dave Abrahams" wrote: > > A call to new that throws an exception never allocated memory. No leak. So, > > for your example to be "safe" one must assume that it's the second allocation > > that threw an exception, and that the first has already been fully qualified > > into an auto_ptr. > > Exactly. > > > Sounds reasonable, but I'm not sure the standard enforces > > this to be the case. > > It does, whether you're sure or not. Arguments are completely evaluated > serially in an indeterminate order. I'm still not convinced. Cite the source for your beliefs here. There's another thread running currently which addresses this self same issue in which many knowledgeable programmers seem to be indicating the compiler is free to evaluate the parameters in any order, including concurrently, and may very well allocate the memory before the auto_ptr's are constructed and thus you'll leak memory. > > In any event, this is an extremely esoteric example, > > contrived to prove a point that's a non-point. > > Not so esoteric, unless you plan to somehow prevent people from using the > results of function calls as arguments to functions. Almost any function can > throw an exception, and the evaluation order of arguments is undefined. > Calling this a non-point seems like a gratuitous insult. It wasn't an insult. Take it that way if you care to. > > I'd have included the pointers > > in an auto_ptr before the call to Adopt2 and ensured I called with a release, > > *IF* I was that concerned about new throwing. > > That doesn't solve the problem in the general case. Evaluating another > argument to a function could always cause an exception. True... hadn't thunk that one through I guess. I'll have to await the next GotW which is supposed to address this issue (again, look for the other thread). > > However, when new throws, the > > majority of the time you are going to have more problems than just a bit of > > leaked memory. Either you've taken the time to code in the capability to > > recover fully from this situation (I've yet to see a real program that does > > this) or one need not worry about a leak in this case. > > But Sir, an exception could come from anywhere, not just operator new. Even > if it were true that it was very difficult to recover from memory allocation > failures (it is not), that wouldn't change anything. It is nigh unto impossible to recover from memory allocation failures. Again, check out the other thread on the subject. And again, I wasn't thinking of other exceptions, because the specific example doesn't lend its self to other exceptions occuring. > Any argument that using auto_ptr is no safer than passing ownership with raw > pointers begins to look a bit silly when you also say that it isn't worth > worrying about what happens when you run out of memory because it's to much > trouble to deal with. How so? > >It means a lot more than that, and that's where the danger in it's use > >as "documentation" lies. Use it to enforce the rules, but don't use it > >to "document" behavior that is purely a side effect (where a side effect is > >behavior of a function that is different or in addition to the normal behavior > >one would expect). > > Every body of code has an "audience", that will be expected to be able to > read and understand it. If you don't think your audience will quickly grasp > the implications of seeing an auto_ptr passed by value, by all means add > comments that explain what's happening. When something becomes idiomatic in > a project it becomes less neccessary to describe each occurrence. That's why > people use naming conventions, for example. You have to decide who you think > you're writing for, and how well they will grasp your common idioms. The "audience" is not fixed. Naming conventions provide good documentation within code, since a good naming convention will explicitly state what's intended. A side effect of a class does not provide the same level of documentation, and in fact can be easily proved to not provide any documentation for some "audience members" and not enough (or easily over looked) information to the rest. Argue about the usefullness of passing an auto_ptr all you want. You may convince me it's a good idea. But if you believe it's a good idea because it documents something then I hope I never have to work with your code. You'll never convince me of that one. --== Sent via Deja.com http://www.deja.com/ ==-- ---Share what you know. Learn what you don't.--- --- [ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]