> > 2. IMO any locking mechanisms should be implemented in terms of smart_ptr > > I don't see the fundamental connection between locking and smart > pointers. > > In particular, which smart_ptr are we talking about? shared_ptr [which > may need locking internally for reference count anyway] > or shared_ptr?
Mutex locking is a simple example of resource management idiom. All flavors of resource management are easily implemented in terms of policy based smart pointers (don't allow name to confuse you). In this particular case most probably all that you need is a custom StoragePolicy. Now you can enjoy all the variety of ownership policies supplied with smart_ptr or design your own for very specific needs. > Why should locks be dynamic rather than stack allocated at all? I'd > have though stack-allocation far more intuitive? smart_pointer based implementation has nothing to do with dynamic/stack memory allocation. Of course it will be stack based. Usage will be very similar to scoped_ptr. But instead of memory it will manage the mutex > -- > AlisdairM Gennadiy. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
