> -----Original Message----- > From: David Abrahams [mailto:[EMAIL PROTECTED] > > "E. Gladyshev" <[EMAIL PROTECTED]> writes: > > I am afraid that some of the boost libraries (as they are now) won't > > work for a big group of real time and embedded developers, where > > customization is the key. > > Is it really (other than culturally, I mean)? Are you sure that > there's no good general-purpose allocator which they can use?
What is general purpose? does general purpose include (presumably all at once as iiuyc "there can be only one"): Determinism. Memory usage efficiency. Ability to share allocated objects between threads. Low/no impact on scheduling latency. Speed. Freedom from fragmentation over an arbitrarily long uptime (years). Bonus marks for the last on systems with no mmu. Policy based allocators anyone? But then, I'd probably wan't (need?) policy based smart pointers to use the allocators with. At least some of the above conflicting requirements imply policy decisions about the pointers to this storage. The low latency, but no sharing between threads allocator rather implies that managing the object lifetime using a thread-safe shared_ptr is inefficient at best and dangerous at worst - including the allocator in the type wouldn't be a bad thing here. That suggests to me that policy based smart pointers are the way to go for some (all?) such users/uses. I don't think this in any way detracts from the utility of boost::shared_ptr<> as it stands - a lot of the time, I just "want it to work". Nevertheless there are systems for which which I can't/won't use it (at least not until I've had a chance to digest Peter Dimov's suggestions better). Just one user opinion - ymmv. Regards Darryl Green. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
