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
> > 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)
> > 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. :(
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk