From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-31 14:09:03
----- Original Message -----
From: "bill_kempf" <williamkempf_at_[hidden]>
> 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.
> > 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-
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk