[boost] Proposal for easying smart_ptr usage within C++98

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-05-01 23:10:30

A critique that's made to the nascent smart_ptr derived from Loki is
that, by having many policies, the user might have a hard time using
pre-canned common smart pointer designs. Some of those pre-canned
designs foster binary compatibility, some others emulate weak pointers
that don't dangle, some others perform intrusive or non-intrusive
reference counting etc.

The response often mentioned is that, well, you can typedef a lengthy
smart_ptr instantiation into whatever you like. Hoewever, others note,
the first template argument is more important than the others because
it is the very type the pointer operates on, so it is very likely to
be passed-on by the user. The others are library decisions, and the
user might not want to bother with them.

Then, the discussion goes, in C++0x we'll have typedef templates which
are going to make things so sweet. Yeah right, the rightly infuriated
answer is, by the time the feature will make it into my compiler
vendor's implementation, I might be busy with cashing that 401K, not
with C++.

In this post I would like to make a proposal that I hope would lead to
a setting that would please everybody. The proposal combines the
advantages of policies with a simple syntax.

It's actually nothing new. In short, define a template class 'ptr'
that takes one template argument - the pointee type - and provides
comfortable inner typedefs for all the pre-canned smart pointers
designs that are known to be common. I mean:

template <class T, many parameters>
class smart_ptr
{
    ...
};

template <class T>
struct ptr
{
    typedef T* raw;
    typedef smart_ptr<T, some policies> shared;
    typedef smart_ptr<T, some policies> scoped;
    typedef smart_ptr<T, some policies> scoped_array;
    typedef smart_ptr<T, some policies> weak;
    typedef smart_ptr<T, some policies> std_auto;
};

Then access to these inner types is, I hope palatable to library
users:

void Transmogrify(ptr<Widget>::shared sp);

So users have access to the pre-canned implementations via
ptr<>::some_impl and, very nicely, they also tap into the full power
of custom smart pointers by using smart_ptr. They don't have to worry
about incompatibilities or duplication-related bugs, because the
codebase is not dilluted.

I think that's a reasonable solution, and I wanted to ask for your
opinion on it.

Andrei