Re: [boost] shared_xxx issues

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-09-02 08:46:01

----- Original Message -----
From: "Greg Colvin" <gcolvin_at_[hidden]>

> > In this particular case, I wanted an embedded reference count, a
specialized
> > allocator, and an embedded size which could be passed to the allocator
upon
> > destruction.
>
> Wouldn't Peter's design handle the last two items?

Sorry, I'm not aware of a design by Peter... but in fact, I don't want to
store the size directly. Instead, I want to store the number of elements
(it's an array that I'm managing).

> > Admittedly, the chances that a shared_ptr will be reset to point at the
same
> > object are slim, but if it /does/ happen, there's a good chance that the
> > same code could reset it to point at some other object which is already
> > managed (to see this, ask yourself, "why would a programmer ever
> > intentionally reset() a smart pointer to the same value?"  I can think
of
> > reasons, but it's a bit of a stretch). This is is the only chance we get
to
> > catch a very common source of bugs. Currently, we have a precondition
like
> > this one for reset (is it documented?): "the argument must not point to
an
> > object whose lifetime is managed by another smart pointer...unless it's
the
> > same one that you are calling reset on". I propose to take out the
exception
> > for this one case so that we stand a chance of detecting real bugs.

BTW, I also think that most of these bugs come from shared_ptr construction,
not reset. And there's nothing we can do in the construction case. :(

> If you have a function like
>
>    shared_ptr<stuff> create_stuff(T arg) {
>       return shared_ptr<stuff> (new stuff(arg));
>    }
>
> then a function like
>
>    void recreate_stuff(stuff_ptr& p, T arg) {
>       p.reset(new stuff(arg));
>    }
>
> might be more efficient than
>
>    my_stuff_ptr = create_stuff(arg);

Sure, I guess, but by how much? recreate is still doing a dynamic allocation
and a construction.

-Dave