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
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.
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk