Re: [boost] Re: boost::weak_ptr suggestions

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-04-07 07:04:18

From: "Raoul Gough" <RaoulGough_at_[hidden]>
> > From: "Peter Dimov" <pdimov_at_[hidden]>
> > Changed semantics? Why? Both get() and make_shared() return a NULL
> pointer.
>
> My apologies - I was assuming that make_shared would also throw. I can't
> find make_shared in my copy of boost (1_27_0), but from the name I would
> have thought that it would construct and return a shared_ptr (like
> std::make_pair). Hence my assumption that it would incorporate the
semantics
> of the shared_ptr constructor.

make_shared's intended use is:

weak_ptr<T> wp;

if(shared_ptr<T> p = make_shared(wp))
{
// use p
}

It's in the CVS. weak_ptr has been redesigned since the 1.27.0 release; I
suspect that you won't like some of the changes (lack of operator* and
operator->, for instance.)

The problem with a "standard" weak_ptr is that it's too easy to make costly
mistakes, even in single-threaded code:

void f(T & t);

f(*wp);

If f(), directly or indirectly, reset()s the owning shared_ptr, it's left
with a dangling reference. Of course ordinary pointers have the same problem
too; but when people use a "smart" pointer they expect to be immune from
this kind of error, and the probablity that they will make a mistake
increases. (As Greg Colvin put it, boost smart pointers are "as safe as
possible but no safer.")

I'm not convinced that even leaving get() in is a good idea. We should
probably rename it to unsafe_get() since no matter how red, bold, and large
we make the warning in the documentation, people will ignore it. And it's
not possible to change the name of operator* to signal that it's unsafe,
too.

> > This doesn't mean, of course, that we don't need a parameterized smart
> > pointer. Only that (a) shared_ptr is not it, and (b) shared_ptr plus an
> > additional policy parameter is not it.
>
> Well, I don't know - presumably a more parameterized smart pointer would
(at
> least with some parameter combinations) duplicate the functionality of
> shared_ptr, which would then make shared_ptr redundant.

That was the plan.

The main problem with policy-based pointer proposals so far is that nobody
actually sat down and did the work. The only serious proposal is Andrei's
Loki::SmartPtr, which doesn't support (out of the box) neither the array
versions nor the current shared_ptr, and nobody has expressed willingness to
write the necessary paperwork (formal spec, tests, docs, that sort of
thing.)

Saying "why don't we make a policy-based smart pointer" on the list is not
enough (this is not aimed at you personally, merely a general comment.)