Boost logo

Boost :

From: Dave Abrahams (abrahams_at_[hidden])
Date: 1999-07-18 14:34:03


> A couple of examples that spring to mind that would be better off w/
> failure on sharing rather than on acquisition:
>
> /1/ Static initialisation in a dynamically loaded library:
>
> shared_ptr<T> p(new T(...)); // or acquisition from a factory
> function
>
> A failure to initialise p would lead to terminate, even though the
> resource was correctly allocated.

If you're that close to the line in terms of dynamic memory use at static
initialization time, you're not going to get very far in your program
anyway. What happens the first time you pass p to a function (hint:
sharing)? What happens when you try to return p from a factory function , as
you suggested above (hint: in general, sharing). Suppose the definition of T
changes to make it a few bytes bigger?

> /2/ An object pooling facility (connections, threads, etc) which had
> custody of a number of many objects, each of which might be costly to
> create or have particular significance wrt their identity. To enable
> sharing out of resources it makes sense if the shared_ptr mechanism is
> used. If the resources can be initialised, it is expected that the
> pool would initialise successfully.

Just start thinking of shared_ptr as requiring a resource (it does) and all
of these problems will evaporate in your mind.

> This suggests the alternative
> model. If a resource is never shared out, this has the benefit that it
> (marginally) reduces the overhead required to manage it (ie the count
> never rises above 1, and no count object is ever allocated).

If it is never shared out the overhead of managing it will be statistically
insignificant. The overhead of a count is negligible. The overhead of
incrementing a count is worth considering.

I don't feel like beating this to an even bloodier death than it's already
suffered, so suffice it to say that I don't like the suggested change, I
think it would make shared_ptr less useful, and it is unneccessarily
complicated. Sorry to be so blunt, but I want to stop arguing about it and I
thought I should summarize my position before signing off. Plus, it's 104 in
shade here X-(

stay cool,
Dave

------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com - Simplifying group communications


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