From -4798830427219586022 X-Google-Thread: f78e5,574518e5c7a60feb X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!newshub.sdsu.edu!cyclone.bc.net!news.alt.net!comp-std-cpp-robomod!not-for-mail From: Geoff Carlton Newsgroups: comp.std.c++ Subject: Re: Revised Allocator Proposal Date: 29 Jul 2005 00:30:24 GMT Organization: "Altopia Corp. - Usenet Access - www.altopia.com" Lines: 44 Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <42e96769$0$5397$5a62ac22@per-qv1-newsreader-01.iinet.net.au> References: <7ibbe1hu4omoqsfibanas46idf9u6i5hjo@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en X-Trace: 1122592617 per-qv1-newsreader-01.iinet.net.au 5397 202.161.16.29 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++:1549 Howard Hinnant wrote: > Indeed it is the unequal (private buffer) application that motivates > option 3 of lwg 431: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1599.html > > If swap exchanges memory ownership between containers, then allocator > state (which may be required to deallocate that memory) should follow > the memory it owns. > Pablo has probably already addressed this point better than I can, but as an average user, I don't agree with this solution. When I've used per-container allocators it has been to optimise cases where I have specific knowledge about the lifetime of the subsystem. Examples would be loading up an xml file using tinyxml or in per-render operations, where the data is cleaned up after each render completes. In both these examples, it would be a disaster if some of the resources got out of sync and tried to hang around. Its not the container lifetime thats important here, its the overall subsystem lifetime. Somewhere, in some other system, would live a different container that is quite happy to hang around with my buffer allocator, but I want that buffer back! Although in this case a swap is slow I fail to see how any other solution is valid. The next best would be to throw an exception, but why should correct code suddenly fail due to a lack of optimisation? We may as well start throwing exceptions if people insert near the front of a vector. I'd rather use swap knowing it is blindingly fast when possible, and correct always. All other solutions seem to end up with a swap that is always blindingly fast, and correct when possible. Geoff --- [ 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 ]