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
> > 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
> > user." That's like... like... like making vector<T> not a vector for
> > Let me speak on the user's behalf here: I am perfectly capable of using
> > 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?
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
* 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
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
> > 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
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk