Re: mutex_traits<>

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-01-31 14:26:03

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> 
> ----- Original Message -----
> From: "bill_kempf" <williamkempf_at_h...>
> 
> > Again, the free function approach doesn't discourage usage
> > by "newbies".  I've seen many MT libraries that expose 
lock/unlock on
> > the mutex class's public interface (which is equivalent to free
> > functions) as well as providing the Scoped Lock classes 
for "safer"
> > usage.  Despite documentation warning of the issues most "newbies"
> > invariably call lock/unlock directly instead of using the Scoped
> > Lock, and the result is usually buggy programs that seem to run
> > during testing but deadlock when software is released.  Maybe I'm
> > trying to hard, but I want to prevent this newbie mistake while 
not
> > preventing the experts from easily extending the library in ways 
that
> > scoped locking causes problems.
> 
> ...so you give newbies a "safe_mutex" on which scoped_lock works 
and for
> which there are no lock/unlock functions? Maybe I'm just getting 
hung up on
> the principle of the thing. After all, even experts are likely to 
use
> scoped_lock most often.
> 
> Here's an idea: don't provide lock(), but give scoped_lock a release
()
> function in case an expert needs to leave the mutex locked. Newbies 
are
> unlikely to unlock() a mutex if they can't lock() it.

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.  This 
would probably just cause confusion even for the "experts".

> > > BTW, I note that traits classes normally don't have functions
> > > (numeric_limits<>::min()/max() are nasty outliers), so that also
> > grates on
> > > me a bit as un-idiomatic?
> >
> > std::char_traits<> has 14 static functions.  Is it really un-
> > idiomatic?
> 
> Kinda. "Traits" usually means "information about". Maybe the 
standard
> violates that "rule" occasionally, but I think most other traits 
classes
> don't. I could be wrong, of course.

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?

Bill Kempf