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? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost