|
Boost-Commit : |
Subject: [Boost-commit] svn:boost r82072 - in trunk: boost/atomic/detail libs/atomic/doc libs/atomic/test
From: tim_at_[hidden]
Date: 2012-12-18 04:43:26
Author: timblechmann
Date: 2012-12-18 04:43:23 EST (Tue, 18 Dec 2012)
New Revision: 82072
URL: http://svn.boost.org/trac/boost/changeset/82072
Log:
atomic: fix typos
fixes #7804
Text files modified:
trunk/boost/atomic/detail/gcc-armv6plus.hpp | 2 +-
trunk/boost/atomic/detail/gcc-ppc.hpp | 2 +-
trunk/boost/atomic/detail/linux-arm.hpp | 2 +-
trunk/libs/atomic/doc/atomic.hpp | 8 ++++----
trunk/libs/atomic/doc/atomic.qbk | 8 ++++----
trunk/libs/atomic/doc/platform.qbk | 4 ++--
trunk/libs/atomic/test/atomicity.cpp | 2 +-
7 files changed, 14 insertions(+), 14 deletions(-)
Modified: trunk/boost/atomic/detail/gcc-armv6plus.hpp
==============================================================================
--- trunk/boost/atomic/detail/gcc-armv6plus.hpp (original)
+++ trunk/boost/atomic/detail/gcc-armv6plus.hpp 2012-12-18 04:43:23 EST (Tue, 18 Dec 2012)
@@ -57,7 +57,7 @@
// indicates the mode, so 1 is added to indicate that the destination code is Thumb.
// A temporary register is needed for the address and is passed as an argument to these
// macros. It must be one of the "low" registers accessible to Thumb code, specified
-// usng the "l" attribute in the asm statement.
+// using the "l" attribute in the asm statement.
//
// Architecture v7 introduces "Thumb 2", which does include (almost?) all of the ARM
// instruction set. So in v7 we don't need to change to ARM mode; we can write "universal
Modified: trunk/boost/atomic/detail/gcc-ppc.hpp
==============================================================================
--- trunk/boost/atomic/detail/gcc-ppc.hpp (original)
+++ trunk/boost/atomic/detail/gcc-ppc.hpp 2012-12-18 04:43:23 EST (Tue, 18 Dec 2012)
@@ -48,7 +48,7 @@
it that values carried in registers are extended appropriately and
everything falls into place naturally).
- The register constrant "b" instructs gcc to use any register
+ The register constraint "b" instructs gcc to use any register
except r0; this is sometimes required because the encoding for
r0 is used to signify "constant zero" in a number of instructions,
making r0 unusable in this place. For simplicity this constraint
Modified: trunk/boost/atomic/detail/linux-arm.hpp
==============================================================================
--- trunk/boost/atomic/detail/linux-arm.hpp (original)
+++ trunk/boost/atomic/detail/linux-arm.hpp 2012-12-18 04:43:23 EST (Tue, 18 Dec 2012)
@@ -14,7 +14,7 @@
// Intel/Marvell XScale chips like the one in the NSLU2) have only atomic swap.
// On Linux the kernel provides some support that lets us abstract away from
// these differences: it provides emulated CAS and barrier functions at special
-// addresses that are garaunteed not to be interrupted by the kernel. Using
+// addresses that are guaranteed not to be interrupted by the kernel. Using
// this facility is slightly slower than inline assembler would be, but much
// faster than a system call.
//
Modified: trunk/libs/atomic/doc/atomic.hpp
==============================================================================
--- trunk/libs/atomic/doc/atomic.hpp (original)
+++ trunk/libs/atomic/doc/atomic.hpp 2012-12-18 04:43:23 EST (Tue, 18 Dec 2012)
@@ -142,7 +142,7 @@
implement the operation).
The established memory order will be @c order if the operation
- is successful. If the operation is unsuccesful, the
+ is successful. If the operation is unsuccessful, the
memory order will be
- @c memory_order_relaxed if @c order is @c memory_order_acquire ,
@@ -162,7 +162,7 @@
\param desired Desired new value
\param success_order Memory ordering constraint if operation
is successful
- \param failure_order Memory ordering constraint if operation is unsuccesful
+ \param failure_order Memory ordering constraint if operation is unsuccessful
\return @c true if value was changed
Atomically performs the following operation
@@ -215,7 +215,7 @@
where feasible.
The established memory order will be @c order if the operation
- is successful. If the operation is unsuccesful, the
+ is successful. If the operation is unsuccessful, the
memory order will be
- @c memory_order_relaxed if @c order is @c memory_order_acquire ,
@@ -235,7 +235,7 @@
\param desired Desired new value
\param success_order Memory ordering constraint if operation
is successful
- \param failure_order Memory ordering constraint if operation is unsuccesful
+ \param failure_order Memory ordering constraint if operation is unsuccessful
\return @c true if value was changed
Atomically performs the following operation
Modified: trunk/libs/atomic/doc/atomic.qbk
==============================================================================
--- trunk/libs/atomic/doc/atomic.qbk (original)
+++ trunk/libs/atomic/doc/atomic.qbk 2012-12-18 04:43:23 EST (Tue, 18 Dec 2012)
@@ -115,7 +115,7 @@
[section:mutex Enforcing ['happens-before] through mutual exclusion]
-As an introductury example to understand how arguing using
+As an introductory example to understand how arguing using
['happens-before] works, consider two threads synchronizing
using a common mutex:
@@ -142,7 +142,7 @@
at [^m.lock()]. If this is be thread1, then as a consequence,
thread2 cannot succeed at [^m.lock()] before thread1 has executed
[^m.unlock()], consequently A ['happens-before] B in this case.
-By symmetry, if thread2 suceeds at [^m.unlock()] first, we can
+By symmetry, if thread2 succeeds at [^m.unlock()] first, we can
conclude B ['happens-before] A.
Since this already exhausts all options, we can conclude that
@@ -628,7 +628,7 @@
from C++11 as faithfully as possible, there are a few
limitations that cannot be lifted without compiler support:
-* [*Using non-POD-classes as template paramater to `atomic<T>` results
+* [*Using non-POD-classes as template parameter to `atomic<T>` results
in undefined behavior]: This means that any class containing a
constructor, destructor, virtual methods or access control
specifications is not a valid argument in C++98. C++11 relaxes
@@ -666,7 +666,7 @@
of [*Boost.Atomic] compiles and has correct value semantics.
* [*native_api.cpp] verifies that all atomic operations have correct
value semantics (e.g. "fetch_add" really adds the desired value,
- returing the previous). It is a rough "smoke-test" to help weed
+ returning the previous). It is a rough "smoke-test" to help weed
out the most obvious mistakes (for example with overflow,
signed/unsigned extension, ...).
* [*lockfree.cpp] verifies that the [*BOOST_ATOMIC_*_LOCKFREE] macros
Modified: trunk/libs/atomic/doc/platform.qbk
==============================================================================
--- trunk/libs/atomic/doc/platform.qbk (original)
+++ trunk/libs/atomic/doc/platform.qbk 2012-12-18 04:43:23 EST (Tue, 18 Dec 2012)
@@ -68,7 +68,7 @@
Some amount of care must be taken as the "raw" data type
passed in from the user through [^boost::atomic<T>]
is visible here -- it thus needs to be type-punned or otherwise
- manipulated byte-by-byte to avoid using overloaded assigment,
+ manipulated byte-by-byte to avoid using overloaded assignment,
comparison operators and copy constructors.
[endsect]
@@ -302,7 +302,7 @@
[section:platform_atomic_puttogether Putting it altogether]
The template specializations should be put into a header file
-in the [^boost/atomic/detail] directory, preferrably
+in the [^boost/atomic/detail] directory, preferably
specifying supported compiler and architecture in its name.
The file [^boost/atomic/detail/platform.hpp] must
Modified: trunk/libs/atomic/test/atomicity.cpp
==============================================================================
--- trunk/libs/atomic/test/atomicity.cpp (original)
+++ trunk/libs/atomic/test/atomicity.cpp 2012-12-18 04:43:23 EST (Tue, 18 Dec 2012)
@@ -21,7 +21,7 @@
// we get 0.995 probability to detect a race (if there is one).
//
// Overall this yields 0.995 * 0.995 > 0.99 confidence that the
-// operations truely behave atomic if this test program does not
+// operations truly behave atomic if this test program does not
// report an error.
#include <algorithm>
Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk