From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-05-01 05:40:57
From: "David B. Held" <dheld_at_[hidden]>
> "Greg Colvin" <greg_at_[hidden]> wrote in message
> > [...]
> > Using shared_ptr those details are set when the smart pointer
> > is constructed, and need not be revealed to the client. Note that
> > this means that the creator of a smart pointer can change those
> > details without requiring recompilation of its clients, and without
> > breaking binary compatibility.
> So are you suggesting that I, as a clever user of shared_ptr, could
> have one set of "stock" boost::shared_ptr<T>s in one part of my
> app, and a different set of boost::shared_ptr<T>s in a different
> part of my app, where I re-implement shared_ptr to use, say,
> COM ref-counting? Does this violate ODR? Or would I have
> to give my version of shared_ptr a different name? Or is it the
> case that I can only have one implementation of shared_ptr in a
> given app, but it doesn't have to be the "normal" one? I'm really
> unclear on the "changing the details" part.
What I believe Greg means is that, if you have a library function:
you can change the way the T is allocated without breaking any client code;
shared_ptr<T> doesn't change. Behind the scenes, the library can use
intrusive counting, or even return a pointer to a statically allocated
> > I don't see why a policy-based smart pointer template cannot
> > preserve this feature of shared_ptr.
> My understanding is that shared_ptr fixes the Checking policy,
> Conversion policy, and Ownership policy to AssertCheck,
UnspecifiedCheck, to be precise. ;-)
> appropriate policies. It should be trivial to write a
> BoostRefCounted ownership policy that uses the boost::counted_base
> count, provides construction from boost::shared_ptr and
> boost::intrusive_ptr, as well as to Loki::SmartPtr<BoostIntrusive>.
It is, except for the (pointer, deleter) constructor. The question is, what
does this prove? That you can rename shared_ptr<T> to Loki::SmartPtr<T,
The purpose of shared_ptr is:
* to solve the "polymorphic objects in containers" problem;
* to provide a smart pointer that works with incomplete types - helps for
* to provide a standard smart pointer that (a) is the agreed-upon
"transport" for library interoperability, and (b) can be used as a
"firewall" between a library and a client, insulating the client from
library changes (often in tandem with an abstract class.)
* to "just work" in a variety in situations.
The fact that someone can write an ownership policy for it is irrelevant.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk