Boost logo

Boost :

From: Darryl Green (Darryl.Green_at_[hidden])
Date: 2003-08-26 21:28:38


> -----Original Message-----
> From: David Abrahams [mailto:dave_at_[hidden]]
>
> "E. Gladyshev" <egladysh_at_[hidden]> 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.


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