Boost logo

Boost :

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-05-16 14:19:45

----- Original Message -----
From: "Persson Jonas" <jonas.persson_at_[hidden]>

> > One night while trying to fall asleep my mind drifted to this problem
> (yeah, I know what
> > that says about me), and it dawned on me that the standard already has a
> solution to a
> > very similar problem. The std::auto_ptr<> template solves a similar
> through
> > "ownership" and "move semantics" instead of the more traditional copy
> semantics. This
> > allows you to pass a std::auto_ptr<> out of one "scope" and into
> passing the
> > ownership and insuring only one "ptr" will ever delete the object. I
> could apply the
> > same technique to the ScopedLock concepts and allow the lock "ownership"
> to be exclusive
> > and transferrable. In many ways this seems like a much better solution
> then a
> > lock_operations<> template. However, there are issues with "move
> semantics" that have
> > caused a lot of questions about how to use std::auto_ptr<> correctly,
> these issues
> > would exist here as well. Also, I'm not 100% sure this solution will
> cover all use
> > cases where the ScopedLock is problematic. So what I'm looking for is
> comments on
> > whether or not this solution is viable and/or the solution I should
> implement. Thoughts
> > anyone?
> Whats wrong with just using std::auto_ptr<scoped_lock> in these cases?

Nothing other then the need to allocate the lock on the heap, which many
view as a fairly expensive requirement for something so "simple". I've
suggested this resolution before, and it's not popular (and I think rightly

Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at