Re: [boost] Re: Re: intrusive_ptr / shared_ptr.

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-07-19 11:27:43

From: "Ed Brey" <brey_at_[hidden]>
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:004101c22f33$df5432f0$1d00a8c0_at_pdimov2...
> >
> > I have never liked the kind of design where the same class template is
> > "overloaded" to mean different things, depending on what is "best for
the
> > user." That's like... like... like making vector<T> not a vector for
some T!
> >
> > Let me speak on the user's behalf here: I am perfectly capable of using
the
> > appropriate pointer type, thank you very much.
>
> I'm not arguing about the user's capabilities.  I'm looking for an
opportunity to perform an automatic optimization.  For example, no one
complains when std::copy figures out that it is working with PODs and does a
memcpy silently instead.  The user could have type memcpy himself, but he's
even more thankful to not have to.
<

The difference is that the std::copy optimization doesn't affect the
semantics; this is the as-if rule. shared_ptr's current semantics do not
allow the optimization that you want. In order to make the optimization
possible, you need to modify the specification.

[...]

> > This is not an implementation detail. It affects the interface.
>
> I see what you are getting at, assuming your talking about the requirement
that T be complete.  Is there no way for the decision on whether the
compiler elides the couter pointer to be deferred until T is defined?
<

No.

class X;
char a[ sizeof(shared_ptr<X>) ];

For the count to be elided, you need to, at least,

* disallow the situation where an incomplete type that, in its complete
form, derives from counted_base, is used as a template parameter for
shared_ptr;

* disallow the construction of a shared_ptr with a custom deallocator when
the template parameter is derived from counted_base;

* disallow the construction of a shared_ptr from a pointer to a type that is
derived multiply from counted_base, and is therefore not convertible to
counted_base*. :-)

There might be more issues involved.

This optimization doesn't pass my cost/benefit test, your opinion may vary.

> > > 3. Provide equally convenient optimization of shared_ptr<T const> as
> > exists for shared_ptr<T>.
> >
> > I don't understand this point.
>
> My meaning is that if T holds its own count, that count should be used
regardless of whether <T const> or <T> is the template parameter.
<

I think that I've covered this in the other post; the template parameter
doesn't determine the counting strategy, the actual pointer type matters.

> > The current trend in smart pointer development is to multiply, not
reduce,
> > the smart pointer types by using combinatorial techniques. :-)
>
> A single smart pointer class that provides many types based on selection
of orthogonal features is fine.
<

A single class is a single type. A single class template may provide many
types. ;-)