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

From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-08-27 20:18:24

--- Andreas Huber <ah2003_at_[hidden]> wrote:
> Peter Dimov wrote:
> No I haven't, but then again to my knowledge no real-time folks are using
> the library yet. The project I was involved in was doing just fine with
> replacing global new/delete. The co-workers with more experience in the
> real-time field convinced me that a library without separate memory
> management customization capabilities is just plain useless for some
> applications. E.g. as Eugene explained, someone might need to allocate the
> data of some (not all) FSMs on a separate heap (e.g. non-volatile memory),
> so that state can be preserved if power is lost. The machine can then
> continue where it left off when power returns. 

There is another reason for specializing allocations to multiple heaps.
If you are working on fault-tolerant system, you have to have a separate
heap for fault/exception handling.
If you program crashes, the state of the main heap may become unpredictable
what is often the case. 
It is a general practice to create a protected heap just for exception handling.  
BTW: it is true even for desktop application.  Many good books on debugging
discussed this technique.

I am actually using a separate heap in my general purpose exception handler.
My exception handler is quite complex, it creates a log, compresses it, etc.
The nice thing about it that I can still use STL containers 
while processing exceptions. All I had to do is to implement a protected
allocator. I had to write a simple smart pointer for my handler 
to work around Boost limitations.  Basically in my handler, 
I could use almost nothing from Boost except 
the Metaprogramming stuff.

Eugene

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