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

From: Andreas Huber (ah2003_at_[hidden])
Date: 2003-08-27 17:34:28

Peter Dimov wrote:
[snip]
> 1. Banning all dynamic memory allocations and most (often all) third
> party libraries;

I believe that's difficult to achieve in most non-trivial situations.
Especially embedded software almost always has to deal with events carrying
data originating from hardware (interrupts). ISRs must use as few cycles as
possible, so all they usually do is allocate an event an put it into a
queue. Whenever no ISR is running, events are popped out of the queue and
processed.

> 2. Allowing dynamic memory and 3rd party libraries but replacing
> global new/delete (the starightforward C++ way to have total control.)
>
> I haven't heard of a case where 3rd party libraries are only allowed
> if they have an allocator parameter and where global new/delete are
> not taken over. It is very unnatural to replace "new X" with the
> allocator-based abomination everywhere in the code, and the benefits
> aren't that great to justify it.
> But it may be just my ignorance showing through, of course.
>
> This leads me to the obvious question: have you actually received a
> request to add an allocator parameter to the FSM library, or are you
> just second-guessing the requirements of the realtime programmers?

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. Now, I could just as well
support a persistence mechanism, which could be used to save the machine
state in the case of power failure. The problem is that this might take just
 so much longer that the hardware folks have to redimension the
power-failure circuit.

In the embedded/real-time world, it is generally very hard to guess about
what other people need, the hardware spectrum is just too varied.

Regards,

Andreas