Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-08-27 05:48:29


Andreas Huber wrote:
>
> E.g. I hope to convince some of the embedded systems/real-time crowd
> to use the fsm lib I'm currently implementing. I would bet that even
> in 10 years most of them wouldn't even consider using it unless they
> were able to totally control how memory is allocated...

That's a good point, now we have something real to argue about. :-)

I'm not that much into resource-constrained environments myself but from
what I know, total control there is indeed the norm, and it is usually
achieved by:

1. Banning all dynamic memory allocations and most (often all) third party
libraries;

or

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?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk