Re: [boost] Re: what happened to allocators in boost?

From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-08-27 11:37:56

--- David Abrahams <dave_at_[hidden]> wrote:
> "E. Gladyshev" <egladysh_at_[hidden]> writes:
> 
> > Sure he could have replaced the system allocator (I actually suggested it too)
> > but why would he want to do it? 
> > The standard system allocator worked just fine for the rest of his program.
> > Why would he want to implement a full blown memory manager.
> 
> He would not.  He would pick an off-the-shelf memory manager such as
> dlmalloc that has been shown to perform well in a wide variety of
> applications.

Perhaps, he did not want to distribute dlmalloc with his library.
It doen't matter. It is all about choice.
Is dlmalloc deterministic?

> > The problem was that my library had couple classes that get
> > allocated/deleted very often it was the biggest performance hit.  He
> > just overloaded the new/delete in these classes and built a very
> > simple fixed-size memory manager in a separate heap just for that.
> >
> > In fact a program might require different allocation
> > strategies depending on the context.  Replacing the global 
> > new/delete may not be an option.
> 
> Hypothetical or real?

I think that if you are a library developer, you don't necessary 
want to overload the global new/delete for all of you library users.
In this case, overloading new/delete is not really an option, is it?

As for using different allocation strategies in one app.
If you need a deterministic allocator for your data types
that get allocated in an ISR, you can use
a deterministic spicialized allocator in the ISR 
context and the starndard one everywhere else.

Eugene

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com