Refactored to use new note and example environments.

source/algorithms.tex

@@ -624,14 +624,14 @@
 type requirement:
 The type of that argument shall satisfy the requirements
 of a mutable iterator~(\ref{iterator.requirements}).
-\enternote
+\begin{note}
 This requirement does not affect arguments that are named
 \tcode{OutputIterator},
 \tcode{OutputIterator1},
 or
 \tcode{OutputIterator2},
 because output iterators must always be mutable.
-\exitnote
+\end{note}
 
 \pnum
 Both in-place and copying versions are provided for certain
@@ -692,12 +692,12 @@
 apply any non-constant function through the dereferenced iterators.
 
 \pnum
-\enternote
+\begin{note}
 Unless otherwise specified, algorithms that take function objects as arguments
 are permitted to copy those function objects freely. Programmers for whom object
 identity is important should consider using a wrapper class that points to a
 noncopied implementation object such as \tcode{reference_wrapper<T>}~(\ref{refwrap}), or some equivalent solution.
-\exitnote
+\end{note}
 
 \pnum
 When the description of an algorithm gives an expression such as
@@ -798,8 +798,8 @@
 \pnum
 \requires \tcode{Function} shall meet the requirements of
 \tcode{MoveConstructible} (Table~\ref{moveconstructible}).
-\enternote \tcode{Function} need not meet the requirements of
-\tcode{CopyConstructible} (Table~\ref{copyconstructible}). \exitnote
+\begin{note} \tcode{Function} need not meet the requirements of
+\tcode{CopyConstructible} (Table~\ref{copyconstructible}). \end{note}
 
 \pnum
 \effects
@@ -810,9 +810,9 @@
 \tcode{first}
 and proceeding to
 \tcode{last - 1}.
-\enternote If the type of \tcode{first} satisfies the
+\begin{note} If the type of \tcode{first} satisfies the
 requirements of a mutable iterator, \tcode{f} may apply nonconstant
-functions through the dereferenced iterator.\exitnote
+functions through the dereferenced iterator.\end{note}
 
 \pnum
 \returns
@@ -2395,7 +2395,7 @@
 implies
 \tcode{equiv(a, c)}
 \end{itemize}
-\enternote
+\begin{note}
 Under these conditions, it can be shown that
 \begin{itemize}
 \item
@@ -2409,7 +2409,7 @@
 \item
 The induced relation is a strict total ordering.
 \end{itemize}
-\exitnote
+\end{note}
 
 \pnum
 A sequence is
@@ -3985,13 +3985,13 @@
 both of which have the same behavior as the original declaration. The behavior is
 undefined unless the objects in the array pointed to by \tcode{base} are of trivial type.
 
-\enternote
+\begin{note}
 Because the function argument \tcode{compar()} may throw an exception,
 \tcode{bsearch()}
 and
 \tcode{qsort()}
 are allowed to propagate the exception~(\ref{res.on.exception.handling}).
-\exitnote
+\end{note}
 
 \xref
 ISO C 7.10.5.

source/atomics.tex

@@ -230,10 +230,10 @@
 affected memory location.
 \end{itemize}
 
-\enternote Atomic operations specifying \tcode{memory_order_relaxed} are relaxed
+\begin{note} Atomic operations specifying \tcode{memory_order_relaxed} are relaxed
 with respect to memory ordering. Implementations must still guarantee that any
 given atomic access to a particular atomic object be indivisible with respect
-to all other atomic accesses to that object. \exitnote
+to all other atomic accesses to that object. \end{note}
 
 \pnum
 An atomic operation \term{A} that performs a release operation on an atomic
@@ -262,9 +262,9 @@
 \tcode{memory_order_seq_cst}.
 \end{itemize}
 
-\enternote Although it is not explicitly required that \textit{S} include locks, it can
+\begin{note} Although it is not explicitly required that \textit{S} include locks, it can
 always be extended to an order that does include lock and unlock operations, since the
-ordering between those is already included in the ``happens before'' ordering. \exitnote
+ordering between those is already included in the ``happens before'' ordering. \end{note}
 
 \pnum
 For an atomic operation \textit{B} that reads the value of an atomic object \textit{M},
@@ -305,18 +305,18 @@
 
 
 \pnum
-\enternote \tcode{memory_order_seq_cst} ensures sequential consistency only for a
+\begin{note} \tcode{memory_order_seq_cst} ensures sequential consistency only for a
 program that is free of data races and uses exclusively \tcode{memory_order_seq_cst}
 operations. Any use of weaker ordering will invalidate this guarantee unless extreme
 care is used. In particular, \tcode{memory_order_seq_cst} fences ensure a total order
 only for the fences themselves. Fences cannot, in general, be used to restore sequential
-consistency for atomic operations with weaker ordering specifications. \exitnote
+consistency for atomic operations with weaker ordering specifications. \end{note}
 
 \pnum
 Implementations should ensure that no ``out-of-thin-air'' values are computed that
 circularly depend on their own computation.
 
-\enternote For example, with \tcode{x} and \tcode{y} initially zero,
+\begin{note} For example, with \tcode{x} and \tcode{y} initially zero,
 
 \begin{codeblock}
 // Thread 1:
@@ -334,10 +334,10 @@
 possible if the store to \tcode{x} stores \tcode{42}, which circularly depends on the
 store to \tcode{y} storing \tcode{42}. Note that without this restriction, such an
 execution is possible.
-\exitnote
+\end{note}
 
 \pnum
-\enternote The recommendation similarly disallows \tcode{r1 == r2 == 42} in the
+\begin{note} The recommendation similarly disallows \tcode{r1 == r2 == 42} in the
 following example, with \tcode{x} and \tcode{y} again initially zero:
 
 \begin{codeblock}
@@ -352,7 +352,7 @@
 if (r2 == 42) x.store(42, memory_order_relaxed);
 \end{codeblock}
 
-\exitnote
+\end{note}
 
 \pnum
 Atomic read-modify-write operations shall always read the last value
@@ -410,12 +410,12 @@
 type.
 
 \pnum
-\enternote Operations that are lock-free should also be address-free. That is,
+\begin{note} Operations that are lock-free should also be address-free. That is,
 atomic operations on the same memory location via two different addresses will
 communicate atomically. The implementation should not depend on any
 per-process state. This restriction enables communication  by memory that is
 mapped into a process more than once and by memory that is shared between two
-processes. \exitnote
+processes. \end{note}
 
 \rSec1[atomics.types.generic]{Atomic types}
 
@@ -558,8 +558,8 @@
 
 \pnum
 There is a generic class template \tcode{atomic<T>}. The type of the template argument
-\tcode{T} shall be trivially copyable~(\ref{basic.types}). \enternote Type arguments that are
-not also statically initializable may be difficult to use. \exitnote
+\tcode{T} shall be trivially copyable~(\ref{basic.types}). \begin{note} Type arguments that are
+not also statically initializable may be difficult to use. \end{note}
 
 \pnum
 The semantics of the operations on specializations of \tcode{atomic} are defined
@@ -666,9 +666,9 @@
 \end{floattablebase}
 
 \pnum
-\enternote The representation of an atomic specialization need not have the same size as its
+\begin{note} The representation of an atomic specialization need not have the same size as its
 corresponding argument type. Specializations should have the same size whenever possible, as
-this reduces the effort required to port existing code. \exitnote
+this reduces the effort required to port existing code. \end{note}
 
 \rSec1[atomics.types.operations]{Operations on atomic types}
 
@@ -731,11 +731,11 @@
 \end{itemize}
 
 \pnum
-\enternote Many operations are volatile-qualified. The ``volatile as device register''
+\begin{note} Many operations are volatile-qualified. The ``volatile as device register''
 semantics have not changed in the standard. This qualification means that volatility is
 preserved when applying these operations to volatile objects. It does not mean that
 operations on non-volatile objects become volatile. Thus, volatile qualified operations
-on non-volatile objects may be merged under some conditions. \exitnote
+on non-volatile objects may be merged under some conditions. \end{note}
 
 \indexlibrary{\idxcode{atomic type}!constructor}%
 \begin{itemdecl}
@@ -746,9 +746,9 @@
 \pnum
 \effects
 leaves the atomic object in an uninitialized state.
-\enternote
+\begin{note}
 These semantics ensure compatibility with C.
-\exitnote
+\end{note}
 \end{itemdescr}
 
 \indexlibrary{\idxcode{atomic type}!constructor}%
@@ -760,12 +760,12 @@
 \pnum
 \effects Initializes the object with the value \tcode{desired}.
 Initialization is not an atomic operation~(\ref{intro.multithread}).
-\enternote it is possible to have an access to an atomic object \tcode{A}
+\begin{note} it is possible to have an access to an atomic object \tcode{A}
 race with its construction, for example by communicating the address of the
 just-constructed object \tcode{A} to another thread via
 \tcode{memory_order_relaxed} operations on a suitable atomic pointer
 variable, and then immediately accessing \tcode{A} in the receiving thread.
-This results in undefined behavior. \exitnote
+This results in undefined behavior. \end{note}
 \end{itemdescr}
 
 \begin{itemdecl}
@@ -778,13 +778,13 @@
 constant initialization of
 an atomic variable of static storage duration of a type that is
 initialization-compatible with \textit{value}.
-\enternote This operation may need to initialize locks. \exitnote
+\begin{note} This operation may need to initialize locks. \end{note}
 Concurrent access to the variable being initialized, even via an atomic operation,
-constitutes a data race. \enterexample
+constitutes a data race. \begin{example}
 \begin{codeblock}
 atomic<int> v = ATOMIC_VAR_INIT(5);
 \end{codeblock}
-\exitexample
+\end{example}
 \end{itemdescr}
 
 \indexlibrary{\idxcode{atomic type}!\idxcode{atomic_is_lock_free}}%
@@ -811,13 +811,13 @@
 \effects Non-atomically
 initializes \tcode{*object} with value \tcode{desired}. This function shall only be applied
 to objects that have been default constructed, and then only once.
-\enternote
+\begin{note}
 These semantics ensure compatibility with C.
-\exitnote
-\enternote 
+\end{note}
+\begin{note} 
 Concurrent access from another thread, even via an atomic operation, constitutes
 a data race.
-\exitnote
+\end{note}
 
 \end{itemdescr}
 
@@ -1003,16 +1003,16 @@
 \returns The result of the comparison.
 
 \pnum
-\enternote For example, the effect of
+\begin{note} For example, the effect of
 \tcode{atomic_compare_exchange_strong} is
 \begin{codeblock}
 if (memcmp(object, expected, sizeof(*object)) == 0)
   memcpy(object, &desired, sizeof(*object));
 else
   memcpy(expected, object, sizeof(*object));
 \end{codeblock}
-\exitnote
-\enterexample the expected use of the compare-and-exchange operations is as follows. The
+\end{note}
+\begin{example} the expected use of the compare-and-exchange operations is as follows. The
 compare-and-exchange operations will update \tcode{expected} when another iteration of
 the loop is needed.
 \begin{codeblock}
@@ -1021,7 +1021,7 @@
   desired = function(expected);
 } while (!current.compare_exchange_weak(expected, desired));
 \end{codeblock}
-\exitexample
+\end{example}
 
 \pnum
 Implementations should ensure that weak compare-and-exchange operations do not
@@ -1035,7 +1035,7 @@
 the contents of memory referred to by \tcode{expected} and \tcode{object} are
 equal, it may return false and store back to \tcode{expected} the same memory
 contents that were originally there.
-\enternote This
+\begin{note} This
 spurious failure enables implementation of compare-and-exchange on a broader class of
 machines, e.g., load-locked store-conditional machines. A
 consequence of spurious failure is that nearly all uses of weak compare-and-exchange
@@ -1044,15 +1044,15 @@
 When a compare-and-exchange is in a loop, the weak version will yield better performance
 on some platforms. When a weak compare-and-exchange would require a loop and a strong one
 would not, the strong one is preferable.
-\exitnote
+\end{note}
 
 \pnum
-\enternote The \tcode{memcpy} and \tcode{memcmp} semantics of the compare-and-exchange
+\begin{note} The \tcode{memcpy} and \tcode{memcmp} semantics of the compare-and-exchange
 operations may result in failed comparisons for values that compare equal with
 \tcode{operator==} if the underlying type has padding bits, trap bits, or alternate
 representations of the same value. Thus, \tcode{compare_exchange_strong} should be used
 with extreme care. On the other hand, \tcode{compare_exchange_weak} should converge
-rapidly. \exitnote
+rapidly. \end{note}
 \end{itemdescr}
 
 \pnum
@@ -1216,11 +1216,11 @@
 The \tcode{atomic_flag} type provides the classic test-and-set functionality. It has two states, set and clear.
 
 \pnum
-Operations on an object of type \tcode{atomic_flag} shall be lock-free. \enternote Hence
+Operations on an object of type \tcode{atomic_flag} shall be lock-free. \begin{note} Hence
 the operations should also be address-free. No other type requires lock-free operations,
 so the \tcode{atomic_flag} type is the minimum hardware-implemented type needed to
 conform to this International standard. The remaining types can be emulated with
-\tcode{atomic_flag}, though with less than ideal properties. \exitnote
+\tcode{atomic_flag}, though with less than ideal properties. \end{note}
 
 \pnum
 The \tcode{atomic_flag} type shall have standard layout. It shall have a trivial default constructor, a deleted copy constructor, a deleted copy assignment operator, and a trivial destructor.