Boost logo

Boost :

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

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