Re: mutex_traits<>

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-31 15:15:45

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> 
> ----- Original Message ----- 
> From: "bill_kempf" <williamkempf_at_h...>
> 
> 
> > Interesting idea, but in practice I think it actually is more 
> > difficult to use then the "traits" solution.  There'd have to be 
an 
> > overloaded constructor that didn't lock the mutex, but set it's 
> > internal state to indicate that the mutex actually is locked.  
> 
> Why? There would be an unlock() operation, just no lock().

The class has to keep track of a "lock state" in order to know 
whether or not to unlock the mutex in the destructor.  Simply 
constructing the lock using the overloaded constructor that allows 
you to specify not to lock the mutex is not enough here, since the 
destructor won't properly unlock the mutex.

> > This is the sort of thing that I find difficult to learn, because 
> > there are so many violations of the "rules".  Is there a book(s) 
that 
> > describe modern day C++ design choices?
> 
> I don't think so; these are probably just my personal predilections.

Unfortunate.  I have a lot of interest in learning in this area, but 
learning from existing usage is obviously near impossible. :(

Bill Kempf