From -1133911478613647541 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,df06663c0326d841 X-Google-Attributes: gid109fba,public X-Google-Thread: f78e5,df06663c0326d841 X-Google-Attributes: gidf78e5,public From: "Dave Abrahams" Subject: Re: auto_ptr copy semantics Date: 1999/05/27 Message-ID: #1/1 X-Deja-AN: 482725157 Content-Transfer-Encoding: 7bit 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> <7if3ih$frk$1@nnrp1.deja.com> X-Original-Date: Thu, 27 May 1999 00:28:59 -0400 Content-Type: text/plain; charset="US-ASCII" Organization: Road Runner X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBVAwUAN01S6awEuYhIxRhxAQE8aQIAg58u2IT6f0ss4nURKoZZa4wRMN3s5Z0X RW9UwgsWMit4renfsuoYLeR0Wd8YyHgmuw49opSfxhvS/cIC3Hu2zg== =g4mk Mime-Version: 1.0 Newsgroups: comp.lang.c++,comp.std.c++ In article <7if3ih$frk$1@nnrp1.deja.com> , sirwillard@my-dejanews.com wrote: >> 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. If you look at the other thread, you'll see my posts there. I was wrong about the point above, sorry. In fact, concurrent evaluation isn't possible (search a copy of the standard for the word "interleaved"; you'll find the reference), but the rest is right. Using auto_ptr can still solve the problems I mentioned - you just can't use it the way I described! >> > 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). Good idea. >> 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. Sir, A claim that it's impossible is unlikely to impress me, since I have done it successfully myself many times, and have subjected the recovery code to rigorous tests. --- [ 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 ]