Boost logo

Boost :

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
> > preventing the experts from easily extending the library in ways
> > scoped locking causes problems.
> 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
> 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
> 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
> violates that "rule" occasionally, but I think most other traits
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at