Re: [boost] Proposal to add smart_ptr to the boost library

From: Sam Partington (sam.partington_at_[hidden])
Date: 2006-01-31 06:28:09

> That's true.  But it's been my experience that the majority of
> development don't have objects access via multiplethreads or don't run
> in a multithread environment.
> In this environment, you're paying additional price for using
> boost::shared_ptr reference-count logic, but not getting any benefits
> from it.
> With a policy base smart pointer, you can pick and choose what's best
> for paticular requirement, instead of being stuck with a one less than
> optimal method.

Shared_ptr will only include threading support in a multithreaded
environment.  So you only pay for it if there is a possibility of
shared_ptr's being shared across threads.

The problem with letting the developer decide on a per ptr basis
whether or not they need MT support is that users (myself included of
course) tend to make poor choices.  Also code changes, a design which
didn't share ptr objects across threads may well end up sharing ptr
objects as the code matures/is maintained.

Even noticing bugs caused by not marshaling these objects is
difficult, your test code may run fine until your code is run by a
user with a SMP system, or with hyper threading enabled... who knows?

For myself, I would want MT support built in by default.  Its too easy
to get wrong to disable it for performance reasons.  And I don't buy
that a smart pointer has to be the most efficient thing in the world,
how many apps have smart pointer usage as their bottleneck?  If they
do wouldn't it better to work out why its the bottleneck rather than
remove MT safety for a small speed gain on the smart pointer code?

If I understand your implementation correctly making a ptr thread safe
means doing the following :

class A
{
public:
  A()
    : l(m, false)
  {
  }

  void lock() { l.lock(); }
  void unlock() { l.unlock(); }

private:
  mutable boost::mutex m
  boost::scoped_lock l;
};

void intrusive_ptr_lock(A * p)    { p->lock(); };
void intrusive_ptr_unlock(A * p) { p->unlock(); }

...

smart_ptr<A, copy_on_write_policy<intrusive_lock_policy> > ptr(new A);

Thats quite a lot of work, though some of the problem with that is
probably down to the way boost::mutexes are handled.

I think my main problem with a PBSP is the last line of the above code
fragment.  Without template typedefs using them can be ugly as hell.

I kind of feel that what you need is not some one tool to rule them
all but several tools that are good at what they do.  so :

std::auto_ptr
std::tr1::scoped_ptr
std::tr1::shared_ptr
boost::cow_ptr ?
boost::copy_ptr ?

Should be sufficient for most needs? and everyone one of them is a
hell of a lot easier to type than :

boost::smart_ptr<A, boost::copy_on_write_policy<boost::intrusive_lock_policy> >

Sam