From 541385057225051119 X-Google-Thread: f78e5,574518e5c7a60feb X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.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: Mon, 08 Aug 2005 15:30:04 -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: Mon, 8 Aug 2005 15:27:42 CST Lines: 49 NNTP-Posting-Host: 65.182.171.162 X-Trace: sv3-DptManyxMGK96EthOf8O9jituJ5ELv0rpoai5p2t0GKYEFY4MCq5TyA3HKTyV5gHd15nFaFSB5r3IGX!RuH5we3T2huljInAfLlLuYST5dEB3ZJuvxy1crCF6T0CispxcgQbyIRsjPycgjYG+HPofIKe/iyb!ey7pUAMqQkdjdClMou1YZtUECXNmHfbrB2pmJjPo6y/dGMY1Bb94 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++:1719 In article , Andrew Marlow wrote: > On Fri, 29 Jul 2005 23:10:03 +0000, Howard Hinnant wrote: > > 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. > > Could you post details on how you way is different from Pablo's? > > > Specifically I believe we can seamlessly support non-equal arena > > allocators, and with some restrictions, non-equal shared memory > > allocators. > > Some specific details would be nice. Pablo's spec is quite specific. I > realise that it involves a polymorphic default allocator which you dont > like, but what would you do instead? My basic premise is that allocator state should be bound to the memory it has allocated, and that the swap functions for the containers should remain O(1), even when allocators compare non-equal. Here's a brief paper on this issue: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1599.html Today, the swap function, and list::splice are the only opportunities in the library for memory ownership to be transferred away from the allocator that allocated it. Tomorrow you will (probably) need to add to that list: move constructors and move assignment. Move assignment can always be implemented in terms of swap, so that one adds nothing new. Move construction will need to transfer memory ownership from source to target, and thus allocator state should be transferred along too. Today's allocators are required to be neither assignable nor swappable. They will need to become swappable, and move assignable to meet these container demands (or perhaps only swappable if containers are required to move assign using swap). My experiments with arena allocators are showing no problems in doing so. -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 ]