From: David Abrahams (dave_at_[hidden])
Date: 2002-10-17 13:00:48
lock_concept.html - Why aren't we using the safe_bool idiom here?
#1 - "Are lock objects thread safe"? Once again, using "thread safe"
to describe objects and classes is a colloquiallism which I
think is best avoided. How about "Can lock objects be shared
#5 - The second comment says "for the same reason we don't have to
synchronize on construction. But the comment _is_ applied to a
constructor definition. Why not just say "for the same reason"
and stop there?
operator=() contains undefined behavior unless both counter
objects are part of the same array; you could use std::less to
get around this. However, I think a comment which describes why
you're ordering the mutexes in this way would be in order. I
assume it's to prevent deadlocks in the case where thread A does
x = y and thread B does y = x at the same time. I am also moved
to suggest that you define operator< on mutex objects so that
this idiom is harder to get wrong.
Why are we defining an enum value TIME_UTC with ALL_CAPS? Is this
thing really in the global namespace as the documentation implies?
If there's a good reason for this, rationale should be
provided. Also, the docs for this value seem to imply knowledge
that I don't have. How is an enumeration value a "clock type?" is
there some important reference missing here?
More to follow,
-- David Abrahams dave_at_[hidden] * http://www.boost-consulting.com Building C/C++ Extensions for Python: Dec 9-11, Austin, TX http://www.enthought.com/training/building_extensions.html
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk