From: Carlo Wood (carlo_at_[hidden])
Date: 2002-09-03 19:21:56
On Tue, Sep 03, 2002 at 01:03:07PM -0400, Rob Stewart wrote:
> Yes, the user could provide the allocator that does whatever is appropriate for
> the application, and that's not a bad approach. However, using preallocated
> memory is easier than you're making it out to be. All (!) you need to do is
> create an allocator that assigns memory from a large pool that it preallocates.
> IOW, instead of calling a heap function which carves memory out of a large
> chunk, the allocator manages its own (smaller) large chunk. (Note that I'm not
> saying this is easy, but you don't need to decide how much memory to allocate
> for each data structure.)
>
> > Actually, I think that allocators like this should
> > be part of boost too, and NOT as a part of my demangler
> > library, but provided seperately.
>
> That is certainly a valid point. Of course, you could implement it first within
> your library, then submit it for a separate review later. Then, when accepted,
> you could change demangle() to use that new allocator. (Isn't it good that I'm
> here to suggest work for you?) Seriously, if you were to do the work to
> implement your library, it could be the start of a set of commonly needed
> allocators.
Well, from this is shows that you DO understand what we're talking about.
*confused*
Anyway - if I'd add an allocator to the library that does pre-allocation,
then (for the case that I need it) would need to call __libc_malloc in it,
which is not portable. I am not going to explain why. I WOULD implement
the library as one that allows the user to pass an Allocator type though,
and then seperately provide an allocator and a "wrapper". But - I am not
going to do that. The category of users that is not capable of writing
an allocator will not need on imho, they can use std::allocator.
-- Carlo Wood <carlo_at_[hidden]>