Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of lancediduck@nyc.rr.com
 designates 24.29.109.7 as permitted sender)
Message-Id: <200510082247.j98MlKMG000254@ms-smtp-03.rdc-nyc.rr.com>
From: "Lance Diduck" <lancediduck@nyc.rr.com>
To: <stdcxx-dev@incubator.apache.org>
Subject: RE: "Pluggable Memory"
Date: Sat, 8 Oct 2005 18:48:10 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-reply-to: <433DE32C.9070008@roguewave.com>
Thread-index: AcXGJVhzZq+svk6NQs6Es8Zsgs95iAGMZ/fw

The main problem with the allocators is that they tried to do more with
memory that the underlying C memory model is capable of. So its main sin is
that there is a lot of boilerplate that really cant do anything, which is
confusing, and also that the standard put in language that seems to second
guess itself, which makes everybody think they are a hack. 
My company tried these polymorphic allocators in STL containers, and in
large part being replaced now with a compile time solution. They are just
too hard to test.
But private heaps (PluggableMemory) seem to make sense for service
architectures, and for very localized calls. I almost exclusively write
service architecture "plugin" type things, and often find myself wanting
this sort of flexibility. 

-----Original Message-----
From: Martin Sebor [mailto:sebor@roguewave.com] 
Sent: Friday, September 30, 2005 9:15 PM
To: stdcxx-dev@incubator.apache.org
Subject: Re: "Pluggable Memory"

Martin Sebor wrote:
> Lance Diduck wrote:
> 
>> To all: Here is an issue that may impact stdcxx.
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1850.pdf 
[...]
> I skimmed the paper but I suspect I'll need to re-read it and spend
> some time playing with the proposed classes to get a better
> understanding of it. I'll try to do that before the end of the month
> (i.e., before the October WG21 meeting) and post my feedback here.

Okay, I've re-read Pablo's paper and the comp.std.c++ thread (below)
and here are my first thoughts:

I agree that the allocator model has serious problems and I like some
(although not all) aspects of the proposed solution. I have serious
reservations about switching from stateless to polymorphic allocators
as the default. I also share Howard's concern about the extent of the
proposed changes to the library. In addition, intuitively I feel that
it should be possible to solve the general problem in a less invasive
way.

Martin

http://groups.google.com/group/comp.std.c++/browse_thread/thread/574518e5c7a
60feb/ffb77430957a71df