Re: [boost] Re: Re: Smart pointers: One more implementation + question

From: Pavel Vasiliev (pavel_at_[hidden])
Date: 2003-02-05 08:53:14

> Obviously you missed the delights of reading Karl May's Winnetou when you
> were a kid :o).

:-) Yes, I've missed this. I started to read in English not too long
time ago.

[snip]
> Looks great. However, all these behaviors can be, and most were, trivially
> implemented as policies of SmartPtr, while benefitting of all the extra
> amenities, which all your pointers are lacking.

> Seems, however, that I need to refocus my efforts of convincing people that
> SmartPtr is the way to go and design within its framework - the kavorka of
> implementing one's own pet smart pointer is way too overwhelming :o).
>
> Andrei

Andrei, please don't take me wrong. I felt myself inspired after
reading your Modern C++ Design and some articles in CUJ. But I'm
also completely agree with rationale given in QA1-3 at
http://www.boost.org/libs/smart_ptr/shared_ptr.htm#FAQ

(in short: "Parameterization discourages users", "Template parameters
affect the type", "Having a single pointer type is important for
stable library interfaces". Sorry for possible out-of-context citation)

One of great advantages of Loki::SmartPtr is on-the-fly construction
of different smart pointer types.

But not all libraries can be completely implemented in templates
(for which Loki::SmartPtr currently is the way of choice).

Consider the following example:

struct EventSource
{
  virtual
  void registerListener(const smart_ptr<Listener> &) = 0;
}

With policy-based smart pointer this method either forces clients to
use a specific set of policies, or to perform smart pointer type
conversion, that may be expensive or not available at all.

The most obvious advantage of my implementation is that intrusive,
semi-intrusive and non-intrusive ref. counting are all transparently
(and with no performance penalty) supported by the ONLY class refc_ptr<T>.
Therefore with refc_ptr<> the registerListener() method in the above
example doesn't need to care about exact type of allocation of an
Listener object passed to it.

Implementing of refc_ptr as a set of policies is also possible, but
currently that seems to be overkill, both in unnecessary complexity
and performance losses. Though this my opinion may change with time.

Conclusion: IMO, policy-based implementations like Loki::SmartPtr<>
and "fixed" ones like boost::shared_ptr<T> or my refc_ptr<T> serve
different needs. Do I say something new? Hardly.

Pavel