Fixed nesting bugs for notes and examples

source/algorithms.tex

@@ -1089,14 +1089,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
@@ -1157,12 +1157,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
@@ -1223,11 +1223,11 @@
 
 \item
 Operations on those function objects required by the specification.
-\enternote See~\ref{algorithms.general}.\exitnote
+\begin{note} See~\ref{algorithms.general}.\end{note}
 \end{itemize}
 
 These functions are herein called \defn{element access functions}.
-\enterexample
+\begin{example}
 The \tcode{sort} function may invoke the following element access functions:
 
 \begin{itemize}
@@ -1243,7 +1243,7 @@
 \item
 The user-provided \tcode{Compare} function object.
 \end{itemize}
-\exitexample
+\end{example}
 
 \rSec2[algorithms.parallel.user]{Requirements on user-provided function objects}
 
@@ -1272,11 +1272,11 @@
 created by the library to support parallel algorithm execution. Any such
 invocations executing in the same thread are indeterminately sequenced with
 respect to each other.
-\enternote
+\begin{note}
 It is the caller's responsibility to ensure that the
 invocation does not introduce data races or deadlocks.
-\exitnote
-\enterexample
+\end{note}
+\begin{example}
 \begin{codeblock}
 int a[] = {0,1};
 std::vector<int> v;
@@ -1286,8 +1286,8 @@
 \end{codeblock}
 The program above has a data race because of the unsynchronized access to the
 container \tcode{v}.
-\exitexample
-\enterexample
+\end{example}
+\begin{example}
 \begin{codeblock}
 std::atomic<int> x{0};
 int a[] = {1,2};
@@ -1300,8 +1300,8 @@
 The above example depends on the order of execution of the iterations, and
 will not terminate if both iterations are executed sequentially on the same
 thread.
-\exitexample
-\enterexample
+\end{example}
+\begin{example}
 \begin{codeblock}
 int x = 0;
 std::mutex m;
@@ -1313,18 +1313,18 @@
 \end{codeblock}
 The above example synchronizes access to object \tcode{x} ensuring that it is
 incremented correctly.
-\exitexample
+\end{example}
 
 \pnum
 The invocations of element access functions in parallel algorithms invoked with
 an execution policy of type \tcode{parallel_vector_execution_policy} are
 permitted to execute in an unordered fashion in unspecified threads, and
 unsequenced with respect to one another within each thread.
-\enternote
+\begin{note}
 This means that multiple function object invocations may be interleaved on a
 single thread, which overrides the usual guarantee from \ref{intro.execution}
 that function executions do not interleave with one another.
-\exitnote
+\end{note}
 Since \tcode{parallel_vector_execution_policy} allows the execution of element
 access functions to be interleaved on a single thread, synchronization,
 including the use of mutexes, risks deadlock. Thus the synchronization with
@@ -1336,11 +1336,11 @@
 deallocation function. Vectorization-unsafe standard library functions may not
 be invoked by user code called from \tcode{parallel_vector_execution_policy}
 algorithms.
-\enternote
+\begin{note}
 Implementations must ensure that internal synchronization inside standard
 library routines does not induce deadlock.
-\exitnote
-\enterexample
+\end{note}
+\begin{example}
 \begin{codeblock}
 int x = 0;
 std::mutex m;
@@ -1353,13 +1353,13 @@
 The above program may result in two consecutive calls to \tcode{m.lock()} on
 the same thread (which may deadlock), because the applications of the function
 object are not guaranteed to run on different threads.
-\exitexample
-\enternote
+\end{example}
+\begin{note}
 The semantics of the \tcode{parallel_execution_policy} or the
 \tcode{parallel_vector_execution_policy} invocation allow the implementation to
 fall back to sequential execution if the system cannot parallelize an algorithm
 invocation due to lack of resources.
-\exitnote
+\end{note}
 
 \pnum
 The semantics of parallel algorithms invoked with an execution policy object of
@@ -1393,25 +1393,25 @@
 containing all uncaught exceptions
 thrown during the invocations of element access functions,
 or optionally the uncaught exception if there was only one.
-\enternote
+\begin{note}
 For example, when \tcode{for_each} is executed sequentially, if an invocation
 of the user-provided function object throws an exception, \tcode{for_each} can
 exit via the uncaught exception, or throw an \tcode{exception_list} containing
 the original exception.
-\exitnote
-\enternote
+\end{note}
+\begin{note}
 These guarantees imply that, unless the algorithm has failed to allocate memory
 and exits via \tcode{bad_alloc}, all exceptions thrown during the execution of
 the algorithm are communicated to the caller. It is unspecified whether an
 algorithm implementation will ``forge ahead'' after encountering and capturing a
 user exception.
-\exitnote
-\enternote
+\end{note}
+\begin{note}
 The algorithm may exit via the \tcode{bad_alloc} exception even if one or more
 user-provided function objects have exited via an exception. For example, this
 can happen when an algorithm fails to allocate memory while creating or adding
 elements to the \tcode{exception_list} object.
-\exitnote
+\end{note}
 
 \item
 If the execution policy object is of any other type, the behavior is implementation-defined.
@@ -1426,7 +1426,7 @@
 Additionally, each parallel algorithm overload has an additional function
 parameter of type \tcode{ExecutionPolicy\&\&}, which is the first
 function parameter.
-\enternote Not all algorithms have parallel algorithm overloads.\exitnote
+\begin{note} Not all algorithms have parallel algorithm overloads.\end{note}
 
 \pnum
 Unless otherwise specified, the semantics of \tcode{ExecutionPolicy} algorithm
@@ -1504,8 +1504,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
@@ -1516,9 +1516,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
@@ -1553,10 +1553,10 @@
 \effects
 Applies \tcode{f} to the result of dereferencing every iterator in the range
 \range{first}{last}.
-\enternote
+\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
+\end{note}
 
 \pnum
 \complexity
@@ -1581,8 +1581,8 @@
 \pnum
 \requires
 \tcode{Function} shall meet the requirements of \tcode{MoveConstructible}
-\enternote \tcode{Function} need not meet the requirements of
-\tcode{CopyConstructible}. \exitnote
+\begin{note} \tcode{Function} need not meet the requirements of
+\tcode{CopyConstructible}. \end{note}
 
 \pnum
 \requires
@@ -1592,10 +1592,10 @@
 \effects
 Applies \tcode{f} to the result of dereferencing every iterator in the range
 \range{first}{first + n} in order.
-\enternote
+\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
+\end{note}
 
 \pnum
 \returns
@@ -1626,10 +1626,10 @@
 \effects
 Applies \tcode{f} to the result of dereferencing every iterator in the range
 \range{first}{first + n}.
-\enternote
+\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
+\end{note}
 
 \pnum
 \returns
@@ -3005,10 +3005,10 @@
 Copies \tcode{min(last - first, n)} elements (the \defn{sample})
 from \range{first}{last} (the \defn{population}) to \tcode{out}
 such that each possible sample has equal probability of appearance.
-\enternote
+\begin{note}
 Algorithms that obtain such effects include \term{selection sampling}
 and \term{reservoir sampling}.
-\exitnote
+\end{note}
 
 \pnum
 \returns
@@ -3287,7 +3287,7 @@
 implies
 \tcode{equiv(a, c)}
 \end{itemize}
-\enternote
+\begin{note}
 Under these conditions, it can be shown that
 \begin{itemize}
 \item
@@ -3301,7 +3301,7 @@
 \item
 The induced relation is a strict total ordering.
 \end{itemize}
-\exitnote
+\end{note}
 
 \pnum
 A sequence is
@@ -4909,13 +4909,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.