[Boost-commit] svn:boost r85492 - trunk/libs/thread/doc

Subject: [Boost-commit] svn:boost r85492 - trunk/libs/thread/doc
From: vicente.botet_at_[hidden]
Date: 2013-08-27 18:31:32

Author: viboes
Date: 2013-08-27 18:31:32 EDT (Tue, 27 Aug 2013)
New Revision: 85492
URL: http://svn.boost.org/trac/boost/changeset/85492

Log:
Thread: fix some typos in doc.

Text files modified: 
   trunk/libs/thread/doc/external_locking.qbk |     2 +-                                      
   trunk/libs/thread/doc/scoped_thread.qbk    |     4 ++--                                    
   trunk/libs/thread/doc/sync_tutorial.qbk    |     4 ++--                                    
   3 files changed, 5 insertions(+), 5 deletions(-)

Modified: trunk/libs/thread/doc/external_locking.qbk
==============================================================================
--- trunk/libs/thread/doc/external_locking.qbk	Tue Aug 27 16:33:32 2013	(r85491)
+++ trunk/libs/thread/doc/external_locking.qbk	2013-08-27 18:31:32 EDT (Tue, 27 Aug 2013)	(r85492)
@@ -482,7 +482,7 @@
 
 In order to make this code compilable we need to store either a Lockable or a `unique_lock<Lockable>` reference depending on the constructor. Store which kind of reference we have stored,and in the destructor call either to the Lockable `unlock` or restore the ownership.
 
-This seams too complicated to me. Another possibility is to define a nested strict lock class. The drawback is that instead of having only one strict lock we have two and we need either to duplicate every function taking a `strict_lock` or make these function templates functions. The problem with template functions is that we don't profit anymore of the C++ type system. We must add some static metafunction that check that the Locker parameter is a strict lock. The problem is that we can not really check this or can we?. The `is_strict_lock` metafunction must be specialized by the strict lock developer. We need to belive it "sur parole". The advantage is that now we can manage with more than two strict locks without changing our code. Ths is really nice.
+This seams too complicated to me. Another possibility is to define a nested strict lock class. The drawback is that instead of having only one strict lock we have two and we need either to duplicate every function taking a `strict_lock` or make these function templates functions. The problem with template functions is that we don't profit anymore of the C++ type system. We must add some static metafunction that check that the Locker parameter is a strict lock. The problem is that we can not really check this or can we?. The `is_strict_lock` metafunction must be specialized by the strict lock developer. We need to belive it "sur parole". The advantage is that now we can manage with more than two strict locks without changing our code. This is really nice.
 
 Now we need to state that both classes are `strict_lock`s.
 

Modified: trunk/libs/thread/doc/scoped_thread.qbk
==============================================================================
--- trunk/libs/thread/doc/scoped_thread.qbk	Tue Aug 27 16:33:32 2013	(r85491)
+++ trunk/libs/thread/doc/scoped_thread.qbk	2013-08-27 18:31:32 EDT (Tue, 27 Aug 2013)	(r85492)
@@ -190,7 +190,7 @@
 
         explicit scoped_thread(thread&& th) noexcept;
         template <typename F&&, typename ...Args>
-        explicit strict_scoped_thread(F&&, Args&&...);
+        explicit scoped_thread(F&&, Args&&...);
 
         ~scoped_thread();
 
@@ -323,7 +323,7 @@
 [section:call_constructor Move Constructor from a Callable]
 
         template <typename F&&, typename ...Args>
-        explicit strict_scoped_thread(F&&, Args&&...);
+        explicit scoped_thread(F&&, Args&&...);
 
 [variablelist
 

Modified: trunk/libs/thread/doc/sync_tutorial.qbk
==============================================================================
--- trunk/libs/thread/doc/sync_tutorial.qbk	Tue Aug 27 16:33:32 2013	(r85491)
+++ trunk/libs/thread/doc/sync_tutorial.qbk	2013-08-27 18:31:32 EDT (Tue, 27 Aug 2013)	(r85492)
@@ -23,9 +23,9 @@
 In particular, the library provides some lock factories.
 
   template <class Lockable, class Function>
-  auto with_lock_guard(Lockable& m, Function f) -> decltype(fn())
+  auto with_lock_guard(Lockable& m, Function f) -> decltype(f())
   {
-    auto&& _ = boost::make_lock_guard(f);
+    auto&& _ = boost::make_lock_guard(m);
     f();
   }