Re: [boost] Re: Traits-based design and ODR

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
> news:5.1.0.14.0.20020430122950.02e48ce0_at_GMMAIL...
> > [...]
> > 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:

shared_ptr<T> create();

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
object.

> > 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,
BoostRefCounted>?

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
pimples;
* 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.