[Boost-commit] svn:boost r42560 - sandbox/committee/LWG

From: hinnant_at_[hidden]
Date: 2008-01-06 19:00:57

Author: hinnant
Date: 2008-01-06 19:00:56 EST (Sun, 06 Jan 2008)
New Revision: 42560
URL: http://svn.boost.org/trac/boost/changeset/42560

Log:
Checked off V1 20, 21, 27, 28, 31, 33.

Text files modified: 
   sandbox/committee/LWG/issues.html |    12 ++++++------                            
   1 files changed, 6 insertions(+), 6 deletions(-)

Modified: sandbox/committee/LWG/issues.html
==============================================================================
--- sandbox/committee/LWG/issues.html	(original)
+++ sandbox/committee/LWG/issues.html	2008-01-06 19:00:56 EST (Sun, 06 Jan 2008)
@@ -188,7 +188,7 @@
 and put the remaining sentences of the first paragraph in their own
 paragraph
 after this combined paragraph. </p>
-<p>&#9998; 20. [thread.mutex.class] (30.3.1.1), &quot;effects of m.try_lock(): &quot;It is
+<p>&#10004; 20. [thread.mutex.class] (30.3.1.1), &quot;effects of m.try_lock(): &quot;It is
 undefined behavior:&quot; this isn't idiomatic. The undefinedness attaches
 to the
 program, not to the code that causes the problem. The correct phrasing
@@ -196,7 +196,7 @@
 program that does x, y, or z has undefined behavior&quot; or &quot;The behavior
 of a
 program that does x, y, or z is undefined.&quot; </p>
-<p>&#10004; (19), &#9998; (20) 21. [thread.mutex.recursive] (30.3.1.2), see 19, 20. </p>
+<p>&#10004; (19), &#10004; (20) 21. [thread.mutex.recursive] (30.3.1.2), see 19, 20. </p>
 <p>&#10004; 22. [thread.timedmutex.requirements] (30.3.2): &quot;To meet the TimedMutex
 requirements, types are required to meet the Mutex requirements.&quot;
 Instad of
@@ -218,8 +218,8 @@
 <p>&#9998; 26. [thread.timedmutex.requirements] (30.3.2), effects clause for
 timed_lock:
 see 24 (&quot;still&quot;), 25. </p>
-<p>&#10004; (19), &#9998; (20) 27. [thread.timedmutex.class] (30.3.2.1): see 19, 20. </p>
-<p>&#10004; (19), &#9998; (20) 28. [thread.timedmutex.recursive] (30.3.2.2): see 19, 20. </p>
+<p>&#10004; (19), &#10004; (20) 27. [thread.timedmutex.class] (30.3.2.1): see 19, 20. </p>
+<p>&#10004; (19), &#10004; (20) 28. [thread.timedmutex.recursive] (30.3.2.2): see 19, 20. </p>
 <p>&#10004; 29. [thread.lock.intro] (30.3.3), first paragraph: this would be
 clearer in
 the singular: &quot;A lock is an object that holds a reference to a mutex and
@@ -231,12 +231,12 @@
 The next paragraph talks about a lock owning a mutex; this doesn't fit
 the
 model that seems to have been used earlier, that a thread owns a mutex. </p>
-<p>&#9998; 31. [thread.lock.guard] (30.3.3.1), first paragraph of text: see 20. </p>
+<p>&#10004; 31. [thread.lock.guard] (30.3.3.1), first paragraph of text: see 20. </p>
 <p>&#10004; 32. [thread.lock.unique] (30.3.3.2), first paragraph: &quot;An object of type
 unique_lock is not copyable but is movable.&quot; This should be plural:
 &quot;Objects
 of type unique_lock are not copyable but are movable.&quot; </p>
-<p>&#9998; 33. [thread.lock.unique] (30.3.3.2), first paragraph: see 20. </p>
+<p>&#10004; 33. [thread.lock.unique] (30.3.3.2), first paragraph: see 20. </p>
 <p>&#9998; 34. [thread.lock.unique] (30.3.3.2), requirements clauses: mutex() == 0,
 owns_lock() == false; the point of having &quot;exposition only&quot; private
 members is