Phil Endecott-48 wrote:
I wrote something like this to use inside my condition variable implementation and called it "unlock". I think I prefer the name "unlock" to "reverse_lock", personally.
unlock_guard would be even better, IMO. I would love if all "call pairs" in boost had supplied RAII wrappers. When I write my own code I usually force client code to use RAII objects. For instance, I've written my own async signal and slots implementation. It consists of two classes AsyncSignal<> and AsyncSignalConnection. These classes are supplied together and the _only_ way to listen to an AsyncSignal is to create an AsynSignalConnection. If the user really needs to call just disconnect earlier on some runtime condition, they can use scoped_ptr+reset. AsyncSignal<void()> sig; boost::scoped_ptr<AsyncSignalConnection> con(new AsyncSignalConnection(sig, foo_call, ...)); if (...) con.reset(); // disconnect Best Regards, Johan -- View this message in context: http://www.nabble.com/-thread--is-this--reverse_lock-class-a-source-of-error... Sent from the Boost - Dev mailing list archive at Nabble.com.