From 7001080011740015883 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!msrtrans!msrn-in!news.alt.net!comp-std-cpp-robomod!not-for-mail From: Howard Hinnant Newsgroups: comp.std.c++ Subject: Re: Revised Allocator Proposal Date: 29 Jul 2005 23:10:03 GMT Organization: Metrowerks Lines: 82 Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: References: <7ibbe1hu4omoqsfibanas46idf9u6i5hjo@4ax.com> 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: MT-NewsWatcher/3.4 (PPC Mac OS X) X-Complaints-To: abuse@rr.com X-Trace: twister.nyroc.rr.com 1122676284 24.58.14.109 (Fri, 29 Jul 2005 18:31:24 EDT) NNTP-Posting-Date: Fri, 29 Jul 2005 18:31:24 EDT 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 X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU Xref: g2news1.google.com comp.std.c++:1567 In article , Pablo Halpern wrote: > If there were two types of standard swap (e.g. swap_value and > swap_move), then people would eventually learn to pick among them > carefully. A well-written function prototype would have an associated > comment stating whether or not the allocator of the object being passed > in is likely to change, and this issue would be mute. Today the standard only blesses equal-allocators. And the following functionality exists today: Given standard containers of type C, values c1 and c2: To exchange memory ownership you do: swap(c1, c2); To exchange values without exchanging memory ownership you do: {C tmp(c1); c1 = c2; c2 = tmp;} I don't think we need new names for these simple operations. And I really don't think we want to change the observable semantics of either one. And making either one act like the other would be changing observable semantics. Specifically, if swap ceases to exchange memory ownership, changes include: 1. Exception safety goes from nothrow to basic, unless more memory is thrown at the problem to create a strong guarantee. 2. Outstanding iterators/pointers/references are now invalidated. 3. For vector and string, there are observable differences via the capacity() member (capacities are no longer exchanged). 4. Performance goes from O(1) to O(N). 5. Memory swell goes from 0 to N, or if we adopt the strong variant 2N. What we do need to do is add support for unequal allocators. If in doing that, we can preserve the interface (with existing semantics) we already have today, then I believe the programming community will be better off for it. I believe it can be done. > I'd be curious to know how you control when memory is returned from the > arena allocator if the allocator can suddenly end up used by an > unrelated object. Have you ever written an arena allocator that > allocates from a stack buffer? Yes. Speaking not just about allocators and containers, but more broadly, whenever I give a stack based pointer or reference to an object, I am careful to note the relative lifetimes. I am careful when I give an arena allocator to a container, and I am careful when I give a stack-based rdbuf to a stream. > You seem to be dismissing the need to control allocator lifetime, Not at all. I understand that issue and have written much code to ensure such lifetime issues are not violated. I am in sympathy with your motivations. But I believe we can achieve some (not all) of your objectives with far smaller changes to the std::lib. Specifically I believe we can seamlessly support non-equal arena allocators, and with some restrictions, non-equal shared memory allocators. I do not believe we can support a polymorphic default allocator, nor do I believe we can reverse the decision made a decade ago that the choice of allocator effects a container's type (I don't mean to imply that we can't support user-defined polymorphic allocators). -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 ]