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

From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2002-05-17 16:16:40

"William E. Kempf" <williamkempf_at_[hidden]> wrote in message
news:OE68UjACRSRRseCaa2300000b0b_at_hotmail.com...

> Now, rename smart_ptr to smart_resource

typedef smart_ptr smart_resource;

> and move the pointer syntax into a policy and then we'd be closer.
It's already could be managed through policy. The most clean way is to
prohibit dereferencing at compile time using checking policy.

> However, my point was that policies that
> make sense for smart pointers often don't make sense for smart locks.  The

It's always the case: policy written for array does not work for plain
pointer and so on.

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

Don't use (export them). Your smart_lock header could define some storage
policy, checking policy plus several specific ownership policies (you could
probably used some existent).

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

I disagree with the point you are trying to make. IMO oolicy based smart_ptr
could be used safely to implement locks.

>
> Bill Kempf

Gennadiy.