From -865738235309881211 X-Google-Thread: f78e5,574518e5c7a60feb X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!border1.nntp.dca.giganews.com!local01.nntp.dca.giganews.com!nntp.speakeasy.net!news.speakeasy.net.POSTED!not-for-mail NNTP-Posting-Date: Thu, 28 Jul 2005 22:40:17 -0500 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 From: Howard Hinnant Newsgroups: comp.std.c++ Subject: Re: Revised Allocator Proposal Organization: Metrowerks References: <7ibbe1hu4omoqsfibanas46idf9u6i5hjo@4ax.com> <42e96769$0$5397$5a62ac22@per-qv1-newsreader-01.iinet.net.au> User-Agent: MT-NewsWatcher/3.4 (PPC Mac OS X) Message-ID: X-Complaints-To: abuse@rr.com X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Virus-Scanned: amavisd-new at ucar.edu X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Approved: Fergus Henderson , moderator of comp.std.c++ X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Date: Thu, 28 Jul 2005 22:35:07 CST Lines: 57 NNTP-Posting-Host: 65.182.171.162 X-Trace: sv3-aXmcUnsVvZhsbpSednP/gfanRzUGGfvVg1rr1JYOBHTn2s0oVkB3RniLF1f45TqEDEFSXuw4VyHVYW2!K30CsV463N0iJVpOgswFwOEVGH98ANp/5v6dG+dCG5YOC6JFnAs5SzXkBqYef0cyfueUyZDIkpCF!zot5e2/Tf1+PPA1nh6VbGsVGjLkWHN7kRRl8eL0+zaGgYSsG9O4k X-Complaints-To: abuse@speakeasy.net X-DMCA-Complaints-To: abuse@speakeasy.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news1.google.com comp.std.c++:1554 In article <42e96769$0$5397$5a62ac22@per-qv1-newsreader-01.iinet.net.au>, Geoff Carlton wrote: > 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. Thank you for your thoughtful reply. My concern is that an O(N) swap is not always correct. Such a swap can invalidate code which depends on a nothrow exception safety guarantee (as shown in a previous post). Would it be possible for you to post demo code that expresses your concern? I do want to understand it better. -Howard --- [ 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 ]