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

From: William E. Kempf (williamkempf_at_[hidden])
Date: 2002-05-17 15:13:42

----- Original Message -----
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:

1)  I didn't say that a policy based design wouldn't work.
2)  I didn't say you couldn't use the very specific Loki smart_ptr<> to hack
this, I was pointing out there were differences between smart pointers and
smart locks that make melding the two a bad idea.

Now, as for your code... it would work, but it's a bad idea.  A smart lock
is not a smart pointer.  You never use pointer syntax on a lock.  Melding
these two, even in this very specific example, is a bad idea.

Now, rename smart_ptr to smart_resource and move the pointer syntax into a
policy and then we'd be closer.  However, my point was that policies that
make sense for smart pointers often don't make sense for smart locks.  The
best example is a policy of shared ownership.  This common policy in the
domain of pointers is dangerous at best in the domain of locks.

Hopefully this clears up what point I was trying to make.

Bill Kempf