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:[EMAIL PROTECTED] Sent: Friday, September 30, 2005 9:15 PM To: [email protected] 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
