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

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2003-02-05 16:57:07

"Pavel Vasiliev" <pavel_at_[hidden]> wrote in message
news:119691015.20030205155314_at_mpen.bas-net.by...
> > 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.

Same here, I didn't speak *any* English until five years ago, but luckily,
there was a Romanian edition :o).

> 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)

Your agreement with the statements above would naturally lead you to NOT
define yet another smart pointer, but instead, to work on perfecting
shared_ptr. Convictions and actions should best work in agreement. "One
Pointer Type is Good" and "I Have One More Pointer Implementation For You
Guys to Look At" don't go together. So if you were to start work on a
project now, what smart pointer would you use for a stable library
interface? If you'd use yours, does it mean you consider it intrinsically
better than shared_ptr? I think many would disagree for a variety of
objective reasons. (Some of them I mentioned in a reply to shifted_ptr, and
if I'm not wrong they apply to your work as well.) Then you might say, yes,
it all depends on what the project's context is. Then I come and say, /my
point exactly/.

The whole purpose of smart_ptr is to devise a framework that makes it easy
for people like *you* to create their own smart pointers without having to
fight their way through all the syntactic and semantic gunk.

Other posters mentioned undue complexity. I have to say that in a very
egotistical manner I do take credit for what Dave Held mentioned:

    >SmartPtr is not gratuitously complex.
    >There are pretty good reasons for just about every line of code.

I love it when someone who took the time to carefully look through the code
and make efforts to improve (fix :o)) it can see this intent so clearly.
Because indeed, unnecessary complexity (reason of /major/ peeves of mine
with other libraries) is imho not a desirable quality at all. The
introductory chapter "Techniques" of Modern C++ Design was written *last*
(absolutely no exaggeration), and I made a point of putting there
absolutely only stuff that had found practical use within the library, and
to refer to those uses whenever introducing a technique.

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

I believe this is not the case. I firmly believe that the exact behavior
you support can be implemented as ONE ownership policy of SmartPtr (thus
leading you to One Pointer Type) in a clearer manner (subjective criterion)
and in fewer lines of code (objective criterion). Then you would keep the
advantages and have no disadvantage, other than not having the fun of
writing a smart pointer from the ground up.

Not that I don't think the fun aspect ain't important. I think this is my
main problem with Loki::SmartPtr: people seem to have more fun writing
smart pointers from scratch, than writing policies for it. If that persists
over time, then by all means Loki::SmartPtr ain't that cool. Seriously: fun
*is* important :o).

Andrei