Re: [boost] shared_xxx issues

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-09-02 09:33:15

From: David Abrahams <david.abrahams_at_[hidden]>
> 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).

http://groups.yahoo.com/group/boost/files/smart_ptr/shared_ptr_update.zip

There is a constructor like this

  template<typename Deleter> shared_ptr(T * p, Deleter d): px(p), pn(p, d)
  {
  }

that lets you pass in a Deleter function or function object.  Your function
object could capture a count to pass to your custom deallocation function.

Providing a shared_array version of this constructor should be easy enough.

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

We could define
   template<typename T, typename Arg1 ...> shared_ptr(Arg1 arg1 ...)
to be equivalent to
   shared_ptr(new T(arg1 ...))
though without any varargs syntax for templates we would need to
provide some number of separate definitions.

But I'm not sure I like this idea.

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

Depends on how fast the allocation and construction is.  It's just an idea
of the top of my head, inspired by so many people complaining about even
the smallest of unecessary overheads.