Re: [boost] Re: Move semantics (was: Boost.Threads Locking Dilemma)

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-05-17 11:22:18

From: "David B. Held" <dheld_at_[hidden]>
> "William E. Kempf" <williamkempf_at_[hidden]> wrote in message
> news:OE481UbDBRArVc4Iu1B000008f4_at_hotmail.com...
> > [...]
> > There are similarities between the ScopedLocking pattern and smart
> > pointers, but there are enough differences to make a lot of the concepts
> > that are valid for smart pointers to be invalid (or at least dangerous)
> > for "smart locks".
>
> Could you please provide some more details?  I'm thinking of a set of
> policies like this:
>
> // Storage Policy
> template <typename Mutex>
> class lock_storage
> {
> protected:
>     typedef Mutex& stored_type;
>     typedef bool pointer_type;
>     typedef bool& reference_type;
>
[...]
> };
>
> // Ownership Policy
> template <typename Mutex>
> class lock_move
> {
[...]
> };
>
> You would then use the disallow_conversion and no_check policies
> for the remaining policies.
>
> smart_ptr<M, lock_move, no_check, disallow_conversion, lock_storage>
>
> should then give you a ScopedLock with move semantics.  Comments?

That's a lot of code! Part of it is probably caused by the non-"standard"
(stored|pointer|reference)_type, but still.

An entity that is that close to std::auto_ptr<M> (only the deallocator is
different) should be simpler to build using the framework (which presumably
can duplicate std::auto_ptr out of the box) - or am I missing something?