From 4470252717941161014 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:07 -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> 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:33:03 CST Lines: 90 NNTP-Posting-Host: 65.182.171.162 X-Trace: sv3-nBEcSJsxh6bQ1YStKWQu8SOEPxMdvHnfEVxuOsDDmp5/15oDM0GCy80aLoCeZQAXrar0RX/tybY7v9Y!V8mxEltz5LA/XZEDw8bmM3R3bfAXEcN7PvqA2XZPg+Ubg9au9d/lFh+QscscxWt3ULBP0TeqfnYh!VSTjDoowGORC4KOTThZGxtPG6SaP6dPq9UfkvqGaiTU3z8EIaBaf 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++:1553 In article , Pablo Halpern wrote: > Both require that the programmer have absolute > control over when the allocator is used and for what. Imagine you > create a string which is intended to be put into shared memory and which > must allocate all of its memory from the same shared memory pool. Now, > assume a typical manipulation function like this: > > void munge(std::string* s) { > std::string tmp; > // Create a value for tmp using segments of *s > s->swap(tmp); // Reflect changes into s > } > > std::string* mySharedStringPtr = > new(SharedMemAllocator) std::string(SharedMemAllocator); > > munge(mySharedStringPtr); > > If swap exchanges the allocators, then the contents of > *mySharedStringPtr are no longer shared! Worse, mySharedStringPtr > continues to point to a shared memory object which now contains a > pointer to unshared memory. But the solution to this problem is already in common use today (and is also in your paper): void munge(std::string* s) { std::string tmp(s->get_allocator()); // Create a value for tmp using segments of *s s->swap(tmp); // Reflect changes into s } Sorry, but I'm not swayed by this argument. Being careful in this way to support non-equal allocators is old news to me (I've been doing it for years). > There are > two main types of useful allocators: arena allocators that provide > higher performance over a limited region of the program and special > allocators that provide shared memory allocation or other special > allocation services. I've built arena allocators and not felt the need for such a drastic redesign of the std::lib to make them safe and efficient. If two containers which are swapped (exchanging memory) also swap allocators, the code continues to work whether or not the two allocators are equal (point to the same arena). I've not built shared memory allocators. But I have had thoughtful discussions with Ion Gaztanaga, author of Shmem on this subject. I understand that problems arise when different containers from different shared memory segments are swapped. But I also understand that this problem does not exist when both shared memory allocators are in the same segment (even if they are not equal). O(N) swaps are no more correct than O(1) swaps with unequal allocators. Either decision can result in broken code. Hobbling all container swaps with O(N) behavior when two allocators are not equal, just to support the one case of different-segment shared memory allocators does not seem like a good deal to me. The existence of unequal arena allocators, and same-segment but unequal shared memory allocators that will benefit from O(1) swaps, combined with the O(N) performance gain and nothrow exception guarantee strongly tilt the decision in favor of O(1) swap imho. Additionally, if container::swap is always O(1), then clients needing an O(N) variant of the idea (say for different-segment shared memory containers) can very easily accomplish it with an explicit copy-assign-assign sequence -- no need to introduce a new name like swap_value. If he also needs strong exception safety, changing that to copy-copy-swap-swap isn't overly burdensome. This is all existing interface, no new stuff to learn. Otoh, if swap is sometimes O(N), the client that needs O(1) swap must now rely on a new function with a different name (swap_move) that has the functionality he normally expects out of swap (since 1998). This seems like an error prone interface to me. Just my .02 (you asked). ;-) -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 ]