From 02a4789acadf97e6d6e77d1b154e9ee332ec01f5 Mon Sep 17 00:00:00 2001 From: "Kevin M. Godby" Date: Mon, 21 Mar 2016 15:40:13 -0500 Subject: [PATCH] Refactored to use new note and example environments. --- source/access.tex | 132 +++--- source/algorithms.tex | 96 ++-- source/atomics.tex | 86 ++-- source/basic.tex | 482 +++++++++---------- source/classes.tex | 280 +++++------ source/compatibility.tex | 4 +- source/containers.tex | 60 +-- source/conversions.tex | 70 +-- source/declarations.tex | 542 ++++++++++----------- source/declarators.tex | 480 +++++++++---------- source/derived.tex | 160 +++---- source/diagnostics.tex | 28 +- source/exceptions.tex | 116 ++--- source/expressions.tex | 662 +++++++++++++------------- source/future.tex | 18 +- source/intro.tex | 224 ++++----- source/iostreams.tex | 332 ++++++------- source/iterators.tex | 66 +-- source/lex.tex | 138 +++--- source/lib-intro.tex | 152 +++--- source/locales.tex | 90 ++-- source/macros.tex | 18 +- source/numerics.tex | 128 ++--- source/overloading.tex | 314 ++++++------- source/preprocessor.tex | 52 +-- source/regex.tex | 62 +-- source/special.tex | 414 ++++++++-------- source/statements.tex | 104 ++--- source/strings.tex | 36 +- source/support.tex | 120 ++--- source/templates.tex | 984 +++++++++++++++++++-------------------- source/threads.tex | 268 +++++------ source/utilities.tex | 520 ++++++++++----------- 33 files changed, 3622 insertions(+), 3616 deletions(-) diff --git a/source/access.tex b/source/access.tex index 2858b3f5b8..f74ceb2aa1 100644 --- a/source/access.tex +++ b/source/access.tex @@ -50,7 +50,7 @@ are \tcode{public} by default. -\enterexample +\begin{example} \begin{codeblock} class X { @@ -61,20 +61,20 @@ int a; // \tcode{S::a} is public by default }; \end{codeblock} -\exitexample +\end{example} \pnum Access control is applied uniformly to all names, whether the names are referred to from declarations or expressions. -\enternote +\begin{note} Access control applies to names nominated by \tcode{friend} declarations~(\ref{class.friend}) and \grammarterm{using-declaration}{s}~(\ref{namespace.udecl}). -\exitnote +\end{note} In the case of overloaded function names, access control is applied to the function selected by overload resolution. -\enternote +\begin{note} Because access control applies to names, if access control is applied to a typedef name, only the accessibility of the typedef name itself is considered. The accessibility of the entity referred to by the typedef is not considered. @@ -92,7 +92,7 @@ A::B y; // access error, \tcode{A::B} is private } \end{codeblock} -\exitnote +\end{note} \pnum It should be noted that it is @@ -114,9 +114,9 @@ entity, including parts of the declaration preceding the name of the entity being declared and, if the entity is a class, the definitions of members of the class appearing outside the class's \grammarterm{member-specification}{.} -\enternote this access also applies to implicit references to constructors, -conversion functions, and destructors. \exitnote -\enterexample +\begin{note} this access also applies to implicit references to constructors, +conversion functions, and destructors. \end{note} +\begin{example} \begin{codeblock} class A { @@ -162,7 +162,7 @@ \grammarterm{base-specifier} is well-formed because \tcode{D} is derived from \tcode{A}, so checking of \grammarterm{base-specifier}{s} must be deferred until the entire \grammarterm{base-specifier-list} has been seen. -\exitexample +\end{example} \pnum \indextext{argument!access checking~and default}% @@ -176,7 +176,7 @@ \pnum The names in a default \grammarterm{template-argument}~(\ref{temp.param}) have their access checked in the context in which they appear rather than at any -points of use of the default \grammarterm{template-argument}. \enterexample +points of use of the default \grammarterm{template-argument}. \begin{example} \begin{codeblock} class B { }; template class C { @@ -189,7 +189,7 @@ D >* d; // access error, C::TT is protected \end{codeblock} -\exitexample +\end{example} \rSec1[class.access.spec]{Access specifiers}% \indextext{access~specifier} @@ -209,7 +209,7 @@ until the end of the class or until another \grammarterm{access-specifier} is encountered. -\enterexample +\begin{example} \begin{codeblock} class X { @@ -219,11 +219,11 @@ int c; // \tcode{X::c} is public }; \end{codeblock} -\exitexample +\end{example} \pnum Any number of access specifiers is allowed and no particular order is required. -\enterexample +\begin{example} \begin{codeblock} struct S { @@ -236,17 +236,17 @@ int d; // \tcode{S::d} is public }; \end{codeblock} -\exitexample +\end{example} \pnum -\enternote The effect of access control on the order of allocation -of data members is described in~\ref{class.mem}.\exitnote +\begin{note} The effect of access control on the order of allocation +of data members is described in~\ref{class.mem}.\end{note} \pnum When a member is redeclared within its class definition, the access specified at its redeclaration shall be the same as at its initial declaration. -\enterexample +\begin{example} \begin{codeblock} struct S { @@ -257,17 +257,17 @@ enum E: int { e0 }; // error: cannot change access }; \end{codeblock} -\exitexample +\end{example} \pnum -\enternote +\begin{note} In a derived class, the lookup of a base class name will find the injected-class-name instead of the name of the base class in the scope in which it was declared. The injected-class-name might be less accessible than the name of the base class in the scope in which it was declared. -\exitnote +\end{note} -\enterexample +\begin{example} \begin{codeblock} class A { }; class B : private A { }; @@ -276,7 +276,7 @@ ::A* q; // OK }; \end{codeblock} -\exitexample +\end{example} \rSec1[class.access.base]{Accessibility of base classes and base class members}% \indextext{access control!base~class}% @@ -333,7 +333,7 @@ is assumed when the class is defined with the \grammarterm{class-key} \tcode{class}. -\enterexample +\begin{example} \begin{codeblock} class B { /* ... */ }; @@ -363,10 +363,10 @@ \tcode{D7} and \tcode{D8}. -\exitexample +\end{example} \pnum -\enternote +\begin{note} A member of a private base class might be inaccessible as an inherited member name, but accessible directly. Because of the rules on pointer conversions~(\ref{conv.ptr}) and explicit casts~(\ref{expr.cast}), a conversion from a pointer to a derived class to a pointer @@ -398,7 +398,7 @@ bp2->mi = 3; // OK: access through a pointer to \tcode{B}. } \end{codeblock} -\exitnote +\end{note} \pnum A base class @@ -451,7 +451,7 @@ \term{R}. \end{itemize} -\enterexample +\begin{example} \begin{codeblock} class B { public: @@ -471,12 +471,12 @@ } }; \end{codeblock} -\exitexample +\end{example} \pnum If a base class is accessible, one can implicitly convert a pointer to a derived class to a pointer to that base class~(\ref{conv.ptr}, \ref{conv.mem}). -\enternote +\begin{note} It follows that members and friends of a class \tcode{X} @@ -484,12 +484,12 @@ \tcode{X*} to a pointer to a private or protected immediate base class of \tcode{X}. -\exitnote +\end{note} The access to a member is affected by the class in which the member is named. This naming class is the class in which the member name was looked up and found. -\enternote +\begin{note} This class can be explicit, e.g., when a \grammarterm{qualified-id} is used, or implicit, e.g., when a class member access operator~(\ref{expr.ref}) is used (including cases where an implicit @@ -506,7 +506,7 @@ \grammarterm{qualified-id} (that is, \tcode{T}). -\exitnote +\end{note} A member \tcode{m} is accessible at the point @@ -559,7 +559,7 @@ \term{R} when named in class \tcode{B}. -\enterexample +\begin{example} \begin{codeblock} class B; @@ -574,7 +574,7 @@ // and \tcode{f} has access to \tcode{i} in \tcode{A} } \end{codeblock} -\exitexample +\end{example} \end{itemize} \pnum @@ -586,10 +586,10 @@ ``\tcode{.}'' operator case) cannot be implicitly converted to a pointer to the naming class of the right operand. -\enternote +\begin{note} This requirement is in addition to the requirement that the member be accessible as named. -\exitnote +\end{note} \rSec1[class.friend]{Friends}% \indextext{friend function!access and}% @@ -601,7 +601,7 @@ A class specifies its friends, if any, by way of friend declarations. Such declarations give special access rights to the friends, but they do not make the nominated friends members of the befriending class. -\enterexample +\begin{example} the following example illustrates the differences between members and friends: \indextext{friend function!member~function~and}% @@ -625,14 +625,14 @@ obj.member_set(10); } \end{codeblock} -\exitexample +\end{example} \pnum \indextext{friend!class access~and}% Declaring a class to be a friend implies that the names of private and protected members from the class granting friendship can be accessed in the \grammarterm{base-specifier}{s} and member declarations of the befriended -class. \enterexample +class. \begin{example} \begin{codeblock} class A { @@ -647,8 +647,8 @@ }; }; \end{codeblock} -\exitexample -\enterexample +\end{example} +\begin{example} \begin{codeblock} class X { @@ -664,15 +664,15 @@ int v[X::a]; // error: \tcode{X::a} is private }; \end{codeblock} -\exitexample +\end{example} -A class shall not be defined in a friend declaration. \enterexample +A class shall not be defined in a friend declaration. \begin{example} \begin{codeblock} class A { friend class B { }; // error: cannot define class in friend declaration }; \end{codeblock} -\exitexample +\end{example} \pnum A \tcode{friend} declaration that does not declare a function @@ -684,12 +684,12 @@ \terminal{friend} typename-specifier \terminal{;} \end{ncsimplebnf} -\enternote A \tcode{friend} declaration may be the +\begin{note} A \tcode{friend} declaration may be the \term{declaration} in a \grammarterm{template-declaration} -(Clause~\ref{temp}, \ref{temp.friend}).\exitnote If the +(Clause~\ref{temp}, \ref{temp.friend}).\end{note} If the type specifier in a \tcode{friend} declaration designates a (possibly cv-qualified) class type, that class is declared as a friend; otherwise, the -\tcode{friend} declaration is ignored. \enterexample +\tcode{friend} declaration is ignored. \begin{example} \begin{codeblock} class C; @@ -712,7 +712,7 @@ R rc; // \tcode{class C} is a friend of \tcode{R} R Ri; // OK: \tcode{"friend int;"} is ignored \end{codeblock} -\exitexample +\end{example} \pnum \indextext{friend function!linkage~of}% @@ -732,7 +732,7 @@ a class \tcode{Y}. \indextext{member function!friend}% -\enterexample +\begin{example} \begin{codeblock} class Y { @@ -741,14 +741,14 @@ friend X::~X(); // destructors can be friends }; \end{codeblock} -\exitexample +\end{example} \pnum \indextext{friend function!inline}% A function can be defined in a friend declaration of a class if and only if the class is a non-local class~(\ref{class.local}), the function name is unqualified, and the function has namespace scope. -\enterexample +\begin{example} \begin{codeblock} class M { @@ -756,7 +756,7 @@ // not the definition of a member function }; \end{codeblock} -\exitexample +\end{example} \pnum Such a function is implicitly an inline function~(\ref{dcl.fct.spec}). @@ -788,7 +788,7 @@ \pnum \indextext{friend!inheritance~and}% Friendship is neither inherited nor transitive. -\enterexample +\begin{example} \begin{codeblock} class A { @@ -814,7 +814,7 @@ } }; \end{codeblock} -\exitexample +\end{example} \pnum \indextext{local~class!friend}% @@ -831,7 +831,7 @@ subsequently referenced, its name is not found by name lookup until a matching declaration is provided in the innermost enclosing non-class scope. -\enterexample +\begin{example} \begin{codeblock} class X; @@ -851,7 +851,7 @@ Z* pz; // error, no \tcode{Z} is found } \end{codeblock} -\exitexample +\end{example} \rSec1[class.protected]{Protected member access} \indextext{access control!\idxcode{protected}}% @@ -869,7 +869,7 @@ \tcode{C}. All other accesses involve a (possibly implicit) object expression~(\ref{expr.ref}). In this case, the class of the object expression shall be \tcode{C} or a class derived from \tcode{C}. -\enterexample +\begin{example} \begin{codeblock} class B { @@ -915,7 +915,7 @@ p2->i = 3; // ill-formed } \end{codeblock} -\exitexample +\end{example} \rSec1[class.access.virt]{Access to virtual functions}% \indextext{access control!virtual function} @@ -923,7 +923,7 @@ \pnum The access rules (Clause~\ref{class.access}) for a virtual function are determined by its declaration and are not affected by the rules for a function that later overrides it. -\enterexample +\begin{example} \begin{codeblock} class B { @@ -946,7 +946,7 @@ pd->f(); // error: \tcode{D::f()} is private } \end{codeblock} -\exitexample +\end{example} \pnum Access is checked at the call point using the type of the expression used @@ -963,7 +963,7 @@ \pnum If a name can be reached by several paths through a multiple inheritance graph, the access is that of the path that gives most access. -\enterexample +\begin{example} \begin{codeblock} class W { public: void f(); }; @@ -982,7 +982,7 @@ along the public path through \tcode{B}, access is allowed. -\exitexample +\end{example} \rSec1[class.access.nest]{Nested classes}% \indextext{access control!nested class}% @@ -992,7 +992,7 @@ A nested class is a member and as such has the same access rights as any other member. The members of an enclosing class have no special access to members of a nested class; the usual access rules (Clause~\ref{class.access}) shall be obeyed. -\enterexample +\begin{example} \indextext{example!nested~class definition}% \begin{codeblock} @@ -1013,5 +1013,5 @@ } }; \end{codeblock} -\exitexample% +\end{example}% \indextext{access control|)} diff --git a/source/algorithms.tex b/source/algorithms.tex index 7a7f297419..6523c15574 100644 --- a/source/algorithms.tex +++ b/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}~(\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 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 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. diff --git a/source/atomics.tex b/source/atomics.tex index 4ea3573be4..974522abd9 100644 --- a/source/atomics.tex +++ b/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} @@ -561,8 +561,8 @@ \pnum There is a generic class template \tcode{atomic}. 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 @@ -669,9 +669,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} @@ -734,11 +734,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} @@ -749,9 +749,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}% @@ -763,12 +763,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} @@ -781,13 +781,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 v = ATOMIC_VAR_INIT(5); \end{codeblock} -\exitexample +\end{example} \end{itemdescr} \indexlibrary{\idxcode{atomic type}!\idxcode{is_always_lock_free}}% @@ -800,10 +800,10 @@ \pnum The \tcode{static} data member \tcode{is_always_lock_free} is true if the atomic type's operations are always lock-free, and false otherwise. -\enternote +\begin{note} The value of \tcode{is_always_lock_free} is consistent with the value of the corresponding \tcode{ATOMIC_..._LOCK_FREE} macro, if defined. -\exitnote +\end{note} \end{itemdescr} \indexlibrary{\idxcode{atomic type}!\idxcode{atomic_is_lock_free}}% @@ -818,10 +818,10 @@ \begin{itemdescr} \pnum \returns True if the object's operations are lock-free, false otherwise. -\enternote +\begin{note} The return value of the \tcode{is_lock_free} member function is consistent with the value of \tcode{is_always_lock_free} for the same type. -\exitnote +\end{note} \end{itemdescr} \begin{itemdecl} @@ -834,13 +834,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} @@ -1026,7 +1026,7 @@ \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) @@ -1034,8 +1034,8 @@ 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} @@ -1044,7 +1044,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 @@ -1058,7 +1058,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 @@ -1067,15 +1067,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 @@ -1239,11 +1239,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. diff --git a/source/basic.tex b/source/basic.tex index d0eaa0c3a0..15c61c9930 100644 --- a/source/basic.tex +++ b/source/basic.tex @@ -5,7 +5,7 @@ %gram: \pnum -\enternote This Clause presents the basic concepts of the \Cpp language. +\begin{note} This Clause presents the basic concepts of the \Cpp language. It explains the difference between an \term{object} and a \term{name} and how they relate to the value categories for expressions. It introduces the concepts of a @@ -14,12 +14,12 @@ \term{storage} \term{duration}. The mechanisms for starting and terminating a program are discussed. Finally, this Clause presents the \term{fundamental} types of the language and lists the ways of constructing -\term{compound} types from these.\exitnote +\term{compound} types from these.\end{note} \pnum -\enternote This Clause does not cover concepts that affect only a single +\begin{note} This Clause does not cover concepts that affect only a single part of the language. Such concepts are discussed in the relevant -Clauses. \exitnote +Clauses. \end{note} \pnum \indextext{name}% @@ -150,7 +150,7 @@ an explicit specialization~(\ref{temp.expl.spec}) whose \grammarterm{declaration} is not a definition. -\enterexample all but one of the following are definitions: +\begin{example} all but one of the following are definitions: \indextext{example!definition}% \begin{codeblock} @@ -181,10 +181,10 @@ extern X anotherX; // declares \tcode{anotherX} using N::d; // declares \tcode{d} \end{codeblock} -\exitexample +\end{example} \pnum -\enternote +\begin{note} \indextext{implementation-generated}% In some circumstances, \Cpp implementations implicitly define the default constructor~(\ref{class.ctor}), @@ -192,8 +192,8 @@ move constructor~(\ref{class.copy}), copy assignment operator~(\ref{class.copy}), move assignment operator~(\ref{class.copy}), -or destructor~(\ref{class.dtor}) member functions. \exitnote -\enterexample given +or destructor~(\ref{class.dtor}) member functions. \end{note} +\begin{example} given \begin{codeblock} #include @@ -225,12 +225,12 @@ ~C() { } }; \end{codeblock} -\exitexample +\end{example} \pnum -\enternote A class name can also be implicitly declared by an +\begin{note} A class name can also be implicitly declared by an \grammarterm{elaborated-type-specifier}~(\ref{dcl.type.elab}). -\exitnote +\end{note} \pnum \indextext{type!incomplete}% @@ -276,10 +276,10 @@ contains the potential results of the right operand. \item Otherwise, the set is empty. \end{itemize} -\enternote +\begin{note} This set is a (possibly-empty) set of \grammarterm{id-expression}{s}, each of which is either \tcode{e} or a subexpression of \tcode{e}. -\enterexample +\begin{example} In the following example, the set of potential results of the initializer of \tcode{n} contains the first \tcode{S::x} subexpression, but not the second \tcode{S::x} subexpression. @@ -290,8 +290,8 @@ : f(S::x); // \tcode{S::x} is odr-used here, so // a definition is required \end{codeblock} -\exitexample -\exitnote +\end{example} +\end{note} \pnum A variable \tcode{x} whose name appears as a @@ -314,13 +314,13 @@ unless it is a pure virtual function and either its name is not explicitly qualified or the expression forms a pointer to member~(\ref{expr.unary.op}). -\enternote This covers calls to named +\begin{note} This covers calls to named functions~(\ref{expr.call}), operator overloading (Clause~\ref{over}), user-defined conversions~(\ref{class.conv.fct}), allocation function for placement new~(\ref{expr.new}), as well as non-default initialization~(\ref{dcl.init}). A constructor selected to copy or move an object of class type is odr-used even if the -call is actually elided by the implementation~(\ref{class.copy}). \exitnote An allocation +call is actually elided by the implementation~(\ref{class.copy}). \end{note} An allocation or deallocation function for a class is odr-used by a \grammarterm{new-expression} appearing in a potentially-evaluated expression as specified in~\ref{expr.new} and~\ref{class.free}. A deallocation function for a @@ -356,7 +356,7 @@ \indextext{type!incomplete}% Exactly one definition of a class is required in a translation unit if the class is used in a way that requires the class type to be complete. -\enterexample the following complete translation unit is well-formed, +\begin{example} the following complete translation unit is well-formed, even though it never defines \tcode{X}: \begin{codeblock} @@ -364,8 +364,8 @@ struct X* x1; // use \tcode{X} in pointer formation X* x2; // use \tcode{X} in pointer formation \end{codeblock} -\exitexample -\enternote The rules for declarations and expressions +\end{example} +\begin{note} The rules for declarations and expressions describe in which contexts complete class types are required. A class type \tcode{T} must be complete if: @@ -401,7 +401,7 @@ \item an \grammarterm{exception-declaration} has type \tcode{T}, reference to \tcode{T}, or pointer to \tcode{T}~(\ref{except.handle}). \end{itemize} -\exitnote +\end{note} \pnum There can be more than one definition of a class type @@ -465,7 +465,7 @@ implicitly defined in every translation unit where it is odr-used, and the implicit definition in every translation unit shall call the same constructor for a subobject of \tcode{D}. -\enterexample +\begin{example} \begin{codeblock} //translation unit 1: @@ -491,7 +491,7 @@ // \tcode{D()}'s implicit definition // violates the ODR \end{codeblock} -\exitexample +\end{example} \end{itemize} If \tcode{D} is a template and is defined in more than one @@ -530,7 +530,7 @@ declarative region. \pnum -\enterexample +\begin{example} in \begin{codeblock} @@ -551,7 +551,7 @@ the text between \tcode{\{} and \tcode{\}}, but its potential scope excludes the declaration of \tcode{i}. The scope of the second declaration of \tcode{j} is the same as its potential scope. -\exitexample +\end{example} \pnum The names declared by a declaration are introduced into the scope in @@ -573,11 +573,11 @@ all refer to the same variable, non-static data member, or enumerator, or all refer to functions and function templates; in this case the class name or enumeration name is -hidden~(\ref{basic.scope.hiding}). \enternote A namespace name or a +hidden~(\ref{basic.scope.hiding}). \begin{note} A namespace name or a class template name must be unique in its declarative -region~(\ref{namespace.alias}, Clause~\ref{temp}). \exitnote +region~(\ref{namespace.alias}, Clause~\ref{temp}). \end{note} \end{itemize} -\enternote These restrictions apply to the declarative region into which +\begin{note} These restrictions apply to the declarative region into which a name is introduced, which is not necessarily the same as the region in which the declaration occurs. In particular, \grammarterm{elaborated-type-specifier}{s}~(\ref{dcl.type.elab}) and @@ -586,11 +586,11 @@ that region. Local extern declarations~(\ref{basic.link}) may introduce a name into the declarative region where the declaration appears and also introduce a (possibly not visible) name into an enclosing -namespace; these restrictions apply to both regions. \exitnote +namespace; these restrictions apply to both regions. \end{note} \pnum -\enternote The name lookup rules are summarized in~\ref{basic.lookup}. -\exitnote +\begin{note} The name lookup rules are summarized in~\ref{basic.lookup}. +\end{note} \rSec2[basic.scope.pdecl]{Point of declaration} @@ -598,7 +598,7 @@ \indextext{name!point~of declaration}% The \defn{point of declaration} for a name is immediately after its complete declarator (Clause~\ref{dcl.decl}) and before its -\grammarterm{initializer} (if any), except as noted below. \enterexample +\grammarterm{initializer} (if any), except as noted below. \begin{example} \begin{codeblock} unsigned char x = 12; @@ -606,20 +606,20 @@ \end{codeblock} Here the second \tcode{x} is initialized with its own (indeterminate) -value. \exitexample +value. \end{example} \pnum -\enternote +\begin{note} \indextext{name~hiding}% a name from an outer scope remains visible up -to the point of declaration of the name that hides it.\enterexample +to the point of declaration of the name that hides it.\begin{example} \begin{codeblock} const int i = 2; { int i[i]; } \end{codeblock} -declares a block-scope array of two integers. \exitexample \exitnote +declares a block-scope array of two integers. \end{example} \end{note} \pnum The point of declaration for a class or class template first declared by a @@ -640,7 +640,7 @@ \pnum \indextext{declaration!enumerator point~of}% The point of declaration for an enumerator is immediately after its -\grammarterm{enumerator-definition}.\enterexample +\grammarterm{enumerator-definition}.\begin{example} \begin{codeblock} const int x = 12; @@ -648,11 +648,11 @@ \end{codeblock} Here, the enumerator \tcode{x} is initialized with the value of the -constant \tcode{x}, namely 12. \exitexample +constant \tcode{x}, namely 12. \end{example} \pnum After the point of declaration of a class member, the member name can be -looked up in the scope of its class. \enternote +looked up in the scope of its class. \begin{note} \indextext{type!incomplete}% this is true even if the class is an incomplete class. For example, @@ -662,7 +662,7 @@ int b[X::z]; // OK }; \end{codeblock} -\exitnote +\end{note} \pnum The point of declaration of a class first declared in an @@ -691,11 +691,11 @@ declared as a \grammarterm{class-name} in the namespace that contains the declaration; otherwise, except as a friend declaration, the \grammarterm{identifier} is declared in the smallest namespace or block -scope that contains the declaration. \enternote -These rules also apply within templates. \exitnote \enternote Other +scope that contains the declaration. \begin{note} +These rules also apply within templates. \end{note} \begin{note} Other forms of \grammarterm{elaborated-type-specifier} do not declare a new name, and therefore must refer to an existing \grammarterm{type-name}. -See~\ref{basic.lookup.elab} and~\ref{dcl.type.elab}. \exitnote +See~\ref{basic.lookup.elab} and~\ref{dcl.type.elab}. \end{note} \end{itemize} \pnum @@ -710,7 +710,7 @@ \pnum The point of declaration for a template parameter is immediately after its complete -\grammarterm{template-parameter}. \enterexample +\grammarterm{template-parameter}. \begin{example} \begin{codeblock} typedef unsigned char T; @@ -719,21 +719,21 @@ , T // lookup finds the template parameter N = 0> struct A { }; \end{codeblock} -\exitexample +\end{example} \pnum -\enternote Friend declarations refer to functions or classes that are +\begin{note} Friend declarations refer to functions or classes that are members of the nearest enclosing namespace, but they do not introduce new names into that namespace~(\ref{namespace.memdef}). Function declarations at block scope and variable declarations with the \tcode{extern} specifier at block scope refer to declarations that are members of an enclosing namespace, but they do not introduce new names into that scope. -\exitnote +\end{note} \pnum -\enternote For point of instantiation of a template, -see~\ref{temp.point}.\exitnote% +\begin{note} For point of instantiation of a template, +see~\ref{temp.point}.\end{note}% \indextext{scope!declarations and|)} \rSec2[basic.scope.block]{Block scope} @@ -815,7 +815,7 @@ \grammarterm{using-directive}~(\ref{namespace.udir}) that nominates the member's namespace, the member's potential scope includes that portion of the potential scope of the \grammarterm{using-directive} that follows -the member's point of declaration. \enterexample +the member's point of declaration. \begin{example} \begin{codeblock} namespace N { @@ -842,7 +842,7 @@ int q(); // error: different return type } \end{codeblock} -\exitexample +\end{example} \pnum A namespace member can also be referred to after the \tcode{::} scope @@ -891,7 +891,7 @@ body and any portion of the declarator part of such definitions which follows the \grammarterm{declarator-id}, including a \grammarterm{parameter-declaration-clause} and any default -arguments~(\ref{dcl.fct.default})).\enterexample +arguments~(\ref{dcl.fct.default})).\begin{example} \begin{codeblock} typedef int c; @@ -918,7 +918,7 @@ typedef I I; // error, even though no reordering involved }; \end{codeblock} -\exitexample +\end{example} \end{enumeraten} \pnum @@ -960,7 +960,7 @@ parameter names belong to this declarative region; any other kind of name introduced by the \grammarterm{declaration} of a \grammarterm{template-declaration} is instead introduced into the same declarative region where it would be introduced as a result of -a non-template declaration of the same name. \enterexample +a non-template declaration of the same name. \begin{example} \begin{codeblock} namespace N { @@ -978,12 +978,12 @@ the same declarative region --- namely, the \grammarterm{namespace-body} of \tcode{N}. (\tcode{g} is still considered to belong to this declarative region in spite of its being hidden during qualified and unqualified name lookup.) -\exitexample +\end{example} \pnum The potential scope of a template parameter name begins at its point of declaration~(\ref{basic.scope.pdecl}) and ends at the end of its declarative region. -\enternote This implies that a \grammarterm{template-parameter} can be used in the +\begin{note} This implies that a \grammarterm{template-parameter} can be used in the declaration of subsequent \grammarterm{template-parameter}{s} and their default arguments but cannot be used in preceding \grammarterm{template-parameter}{s} or their default arguments. For example, @@ -1003,13 +1003,13 @@ The use of a template parameter as a base class implies that a class used as a template argument must be defined and not just declared when the class template is instantiated. -\exitnote +\end{note} \pnum The declarative region of the name of a template parameter is nested within the -immediately-enclosing declarative region. \enternote As a result, a +immediately-enclosing declarative region. \begin{note} As a result, a \grammarterm{template-parameter} hides any entity with the same name in an enclosing -scope~(\ref{basic.scope.hiding}). \enterexample +scope~(\ref{basic.scope.hiding}). \begin{example} \begin{codeblock} typedef int N; @@ -1018,13 +1018,13 @@ Here, \tcode{X} is a non-type template parameter of type \tcode{int} and \tcode{Y} is a non-type template parameter of the same type as the second template parameter of -\tcode{A}. \exitexample\exitnote +\tcode{A}. \end{example}\end{note} \pnum -\enternote Because the name of a template parameter cannot be redeclared within its +\begin{note} Because the name of a template parameter cannot be redeclared within its potential scope~(\ref{temp.local}), a template parameter's scope is often its potential scope. However, it is still possible for a template parameter name to be hidden; -see~\ref{temp.local}. \exitnote +see~\ref{temp.local}. \end{note} \rSec2[basic.scope.hiding]{Name hiding} @@ -1097,9 +1097,9 @@ and lookup. \pnum -\enternote \ref{basic.link} discusses linkage issues. The notions of +\begin{note} \ref{basic.link} discusses linkage issues. The notions of scope, point of declaration and name hiding are discussed -in~\ref{basic.scope}. \exitnote +in~\ref{basic.scope}. \end{note} \rSec2[basic.lookup.unqual]{Unqualified name lookup} @@ -1123,7 +1123,7 @@ \pnum The lookup for an unqualified name used as the \grammarterm{postfix-expression} of a function call is described -in~\ref{basic.lookup.argdep}. \enternote For purposes of determining +in~\ref{basic.lookup.argdep}. \begin{note} For purposes of determining (during parsing) whether an expression is a \grammarterm{postfix-expression} for a function call, the usual name lookup rules apply. The rules in~\ref{basic.lookup.argdep} have no effect on @@ -1145,7 +1145,7 @@ Because the expression is not a function call, the argument-dependent name lookup~(\ref{basic.lookup.argdep}) does not apply and the friend -function \tcode{f} is not found. \exitnote +function \tcode{f} is not found. \end{note} \pnum A name used in global scope, outside of any function, class or @@ -1169,7 +1169,7 @@ its enclosing blocks~(\ref{stmt.block}) or, shall be declared before its use in namespace \tcode{N} or, if \tcode{N} is a nested namespace, shall be declared before its use in one of \tcode{N}'s enclosing namespaces. -\enterexample +\begin{example} \begin{codeblock} namespace A { @@ -1186,7 +1186,7 @@ // 4) global scope, before the definition of \tcode{A::N::f} } \end{codeblock} -\exitexample +\end{example} \pnum A name used in the definition of a class \tcode{X} outside of a member @@ -1220,7 +1220,7 @@ \tcode{N} or in one of \tcode{N} 's enclosing namespaces. \end{itemize} -\enterexample +\begin{example} \begin{codeblock} namespace M { @@ -1245,15 +1245,15 @@ // 5) global scope, before the definition of \tcode{N} \end{codeblock} -\exitexample \enternote When looking for a prior declaration of a class +\end{example} \begin{note} When looking for a prior declaration of a class or function introduced by a \tcode{friend} declaration, scopes outside of the innermost enclosing namespace scope are not considered; -see~\ref{namespace.memdef}. \exitnote \enternote \ref{basic.scope.class} +see~\ref{namespace.memdef}. \end{note} \begin{note} \ref{basic.scope.class} further describes the restrictions on the use of names in a class definition. \ref{class.nest} further describes the restrictions on the use of names in nested class definitions. \ref{class.local} further describes the restrictions on the use of names in local class -definitions. \exitnote +definitions. \end{note} \pnum For the members of a class \tcode{X}, a name used in a member function @@ -1297,7 +1297,7 @@ or in one of \tcode{N} 's enclosing namespaces. \end{itemize} -\enterexample +\begin{example} \begin{codeblock} class B { }; namespace M { @@ -1319,12 +1319,12 @@ // 5) scope of namespace \tcode{M} // 6) global scope, before the definition of \tcode{M::N::X::f} \end{codeblock} -\exitexample \enternote \ref{class.mfct} and~\ref{class.static} further +\end{example} \begin{note} \ref{class.mfct} and~\ref{class.static} further describe the restrictions on the use of names in member function definitions. \ref{class.nest} further describes the restrictions on the use of names in the scope of nested classes. \ref{class.local} further describes the restrictions on the use of names in local class -definitions. \exitnote +definitions. \end{note} \pnum Name lookup for a name used in the definition of a \tcode{friend} @@ -1344,7 +1344,7 @@ \grammarterm{template-argument} in the \grammarterm{declarator-id}, the look up is as described for unqualified names in the definition of the class -granting friendship. \enterexample +granting friendship. \begin{example} \begin{codeblock} struct A { @@ -1361,7 +1361,7 @@ friend void A::f3(); // template argument is \tcode{B::AT} }; \end{codeblock} -\exitexample +\end{example} \pnum During the lookup for a name used as a default @@ -1370,11 +1370,11 @@ \grammarterm{expression} of a \grammarterm{mem-initializer} for a constructor~(\ref{class.base.init}), the function parameter names are visible and hide the names of entities declared in the block, class or -namespace scopes containing the function declaration. \enternote +namespace scopes containing the function declaration. \begin{note} \ref{dcl.fct.default} further describes the restrictions on the use of names in default arguments. \ref{class.base.init} further describes the restrictions on the use of names in a \grammarterm{ctor-initializer}. -\exitnote +\end{note} \pnum During the lookup of a name used in the @@ -1387,16 +1387,16 @@ A name used in the definition of a \tcode{static} data member of class \tcode{X}~(\ref{class.static.data}) (after the \grammarterm{qualified-id} of the static member) is looked up as if the name was used in a member -function of \tcode{X}. \enternote \ref{class.static.data} further +function of \tcode{X}. \begin{note} \ref{class.static.data} further describes the restrictions on the use of names in the definition of a -\tcode{static} data member. \exitnote +\tcode{static} data member. \end{note} \pnum If a variable member of a namespace is defined outside of the scope of its namespace then any name that appears in the definition of the member (after the \grammarterm{declarator-id}) is looked up as if the definition of the member occurred in its namespace. -\enterexample +\begin{example} \begin{codeblock} namespace N { @@ -1408,7 +1408,7 @@ int N::j = i; // \tcode{N::j == 4} \end{codeblock} -\exitexample +\end{example} \pnum A name used in the handler for a \grammarterm{function-try-block} @@ -1418,12 +1418,12 @@ \grammarterm{exception-declaration} nor in the outermost block of a handler for the \grammarterm{function-try-block}. Names declared in the outermost block of the function definition are not found when looked up in the -scope of a handler for the \grammarterm{function-try-block}. \enternote But -function parameter names are found. \exitnote +scope of a handler for the \grammarterm{function-try-block}. \begin{note} But +function parameter names are found. \end{note} \pnum -\enternote The rules for name lookup in template definitions are -described in~\ref{temp.res}. \exitnote +\begin{note} The rules for name lookup in template definitions are +described in~\ref{temp.res}. \end{note} \rSec2[basic.lookup.argdep]{Argument-dependent name lookup}% \indextext{lookup!argument-dependent} @@ -1438,7 +1438,7 @@ These modifications to the search depend on the types of the arguments (and for template template arguments, the namespace of the template argument). -\enterexample +\begin{example} \begin{codeblock} namespace N { @@ -1454,7 +1454,7 @@ } \end{codeblock} -\exitexample +\end{example} \pnum For each argument type \tcode{T} in the function call, there is a set of @@ -1480,8 +1480,8 @@ template type parameters (excluding template template parameters); the namespaces of which any template template arguments are members; and the classes of which any member templates used as template template -arguments are members. \enternote Non-type template arguments do not -contribute to the set of associated namespaces.\exitnote +arguments are members. \begin{note} Non-type template arguments do not +contribute to the set of associated namespaces.\end{note} \item If \tcode{T} is an enumeration type, its associated namespace is the innermost enclosing namespace of its declaration. If it is a class member, its @@ -1536,10 +1536,10 @@ then \term{Y} is empty. Otherwise \term{Y} is the set of declarations found in the namespaces associated with the argument types as described below. The set of declarations found by the lookup of the name is the -union of \term{X} and \term{Y}. \enternote The namespaces and classes +union of \term{X} and \term{Y}. \begin{note} The namespaces and classes associated with the argument types can include namespaces and classes -already considered by the ordinary unqualified lookup. \exitnote -\enterexample +already considered by the ordinary unqualified lookup. \end{note} +\begin{example} \begin{codeblock} namespace NS { @@ -1555,7 +1555,7 @@ g(parm, 1); // OK: calls \tcode{g(NS::T, float)} } \end{codeblock} -\exitexample +\end{example} \pnum When considering an associated namespace, the lookup is the same as the @@ -1594,7 +1594,7 @@ lookup of the name preceding that \tcode{::} considers only namespaces, types, and templates whose specializations are types. If the name found does not designate a namespace or a class, enumeration, or dependent type, -the program is ill-formed.\enterexample +the program is ill-formed.\begin{example} \begin{codeblock} class A { @@ -1607,19 +1607,19 @@ A b; // ill-formed: \tcode{A} does not name a type } \end{codeblock} -\exitexample +\end{example} \pnum -\enternote Multiply qualified names, such as \tcode{N1::N2::N3::n}, can +\begin{note} Multiply qualified names, such as \tcode{N1::N2::N3::n}, can be used to refer to members of nested classes~(\ref{class.nest}) or -members of nested namespaces. \exitnote +members of nested namespaces. \end{note} \pnum In a declaration in which the \grammarterm{declarator-id} is a \grammarterm{qualified-id}, names used before the \grammarterm{qualified-id} being declared are looked up in the defining namespace scope; names following the \grammarterm{qualified-id} are looked up in the scope of the -member's class or namespace. \enterexample +member's class or namespace. \begin{example} \begin{codeblock} class X { }; @@ -1632,7 +1632,7 @@ // equivalent to: \tcode{::X} \tcode{C::arr[C::number];} // not to: \tcode{C::X} \tcode{C::arr[C::number];} \end{codeblock} -\exitexample +\end{example} \pnum \indextext{scope~resolution~operator}% @@ -1661,7 +1661,7 @@ \end{ncbnf} the second \grammarterm{class-name} is looked up in the same scope as the -first. \enterexample +first. \begin{example} \begin{codeblock} struct C { @@ -1683,8 +1683,8 @@ p->AB::~AB(); // explicitly calls the destructor for \tcode{A} } \end{codeblock} -\exitexample \enternote \ref{basic.lookup.classref} describes how name -lookup proceeds after the \tcode{.} and \tcode{->} operators. \exitnote +\end{example} \begin{note} \ref{basic.lookup.classref} describes how name +lookup proceeds after the \tcode{.} and \tcode{->} operators. \end{note} \rSec3[class.qual]{Class members} @@ -1695,9 +1695,9 @@ \grammarterm{nested-name-specifier} is looked up in the scope of the class~(\ref{class.member.lookup}), except for the cases listed below. The name shall represent one or more members of that class or of one of -its base classes (Clause~\ref{class.derived}). \enternote A class member +its base classes (Clause~\ref{class.derived}). \begin{note} A class member can be referred to using a \grammarterm{qualified-id} at any point in its -potential scope~(\ref{basic.scope.class}). \exitnote The exceptions to +potential scope~(\ref{basic.scope.class}). \end{note} The exceptions to the name lookup rule above are the following: \begin{itemize} @@ -1737,12 +1737,12 @@ \grammarterm{template-name} in the last component of the \grammarterm{nested-name-specifier}, \end{itemize} the name is instead considered to name the -constructor of class \tcode{C}. \enternote For example, the constructor +constructor of class \tcode{C}. \begin{note} For example, the constructor is not an acceptable lookup result in an \grammarterm{elaborated-type-specifier} so the constructor would not be -used in place of the injected-class-name. \exitnote Such a constructor +used in place of the injected-class-name. \end{note} Such a constructor name shall be used only in the \grammarterm{declarator-id} of a declaration -that names a constructor or in a \grammarterm{using-declaration}. \enterexample +that names a constructor or in a \grammarterm{using-declaration}. \begin{example} \begin{codeblock} struct A { A(); }; @@ -1755,7 +1755,7 @@ A::A a; // error, \tcode{A::A} is not a type name struct A::A a2; // object of type \tcode{A} \end{codeblock} -\exitexample +\end{example} \pnum A class member name hidden by a name in a nested declarative region or @@ -1794,7 +1794,7 @@ is the required set of declarations of \tcode{m}. Otherwise if the use of \tcode{m} is not one that allows a unique declaration to be chosen from -$S(X, m)$, the program is ill-formed. \enterexample +$S(X, m)$, the program is ill-formed. \begin{example} \begin{codeblock} int x; @@ -1922,7 +1922,7 @@ B::b++; // OK: \tcode{b} declared directly in \tcode{B}, \tcode{S} is \{\tcode{B::b}\} } \end{codeblock} -\exitexample +\end{example} \pnum During the lookup of a qualified namespace member name, if the lookup @@ -1932,7 +1932,7 @@ functions, the non-type name hides the class or enumeration name if and only if the declarations are from the same namespace; otherwise (the declarations are from different namespaces), the program is ill-formed. -\enterexample +\begin{example} \begin{codeblock} namespace A { @@ -1952,7 +1952,7 @@ int j = C::y; // ambiguous, \tcode{A::y} or \tcode{B::y} } \end{codeblock} -\exitexample +\end{example} \pnum In a declaration for a namespace member in which the @@ -1967,7 +1967,7 @@ \grammarterm{unqualified-id} shall name a member of the namespace designated by the \grammarterm{nested-name-specifier} or of an element of the inline namespace set~(\ref{namespace.def}) of that namespace. -\enterexample +\begin{example} \begin{codeblock} namespace A { @@ -1979,10 +1979,10 @@ void A::f1(int){ } // ill-formed, \tcode{f1} is not a member of \tcode{A} \end{codeblock} -\exitexample However, in such namespace member declarations, the +\end{example} However, in such namespace member declarations, the \grammarterm{nested-name-specifier} may rely on \grammarterm{using-directive}{s} to implicitly provide the initial part of the -\grammarterm{nested-name-specifier}. \enterexample +\grammarterm{nested-name-specifier}. \begin{example} \begin{codeblock} namespace A { @@ -2001,7 +2001,7 @@ using namespace C::D; void B::f1(int){ } // OK, defines \tcode{A::B::f1(int)} \end{codeblock} -\exitexample +\end{example} \indextext{lookup!qualified~name|)}% \rSec2[basic.lookup.elab]{Elaborated type specifiers}% @@ -2049,7 +2049,7 @@ described in~\ref{basic.lookup.qual}, but ignoring any non-type names that have been declared. If the name lookup does not find a previously declared \grammarterm{type-name}, the \grammarterm{elaborated-type-specifier} -is ill-formed. \enterexample +is ill-formed. \begin{example} \begin{codeblock} struct Node { @@ -2082,7 +2082,7 @@ struct Base::Datum; // error: \tcode{Datum} undefined struct Base::Data* pBase; // OK: refers to nested \tcode{Data} \end{codeblock} -\exitexample % +\end{example} % \indextext{lookup!elaborated~type~specifier|)}% \rSec2[basic.lookup.classref]{Class member access} @@ -2114,7 +2114,7 @@ expression is of a class type \tcode{C}, the \grammarterm{type-name} is also looked up in the scope of class \tcode{C}. At least one of the lookups shall find a name that refers to (possibly cv-qualified) -\tcode{T}. \enterexample +\tcode{T}. \begin{example} \begin{codeblock} struct A { }; @@ -2127,7 +2127,7 @@ void B::f(::A* a) { a->~A(); // OK: lookup in \tcode{*a} finds the injected-class-name } -\end{codeblock}\exitexample +\end{codeblock}\end{example} \pnum If the \grammarterm{id-expression} in a class member access is a @@ -2141,9 +2141,9 @@ \tcode{->} operator is first looked up in the class of the object expression and the name, if found, is used. Otherwise it is looked up in the context of the entire -\grammarterm{postfix-expression}. \enternote See~\ref{basic.lookup.qual}, which +\grammarterm{postfix-expression}. \begin{note} See~\ref{basic.lookup.qual}, which describes the lookup of a name before \tcode{::}, which will only find a type -or namespace name. \exitnote +or namespace name. \end{note} \pnum If the \grammarterm{qualified-id} has the form @@ -2169,7 +2169,7 @@ of the entire \grammarterm{postfix-expression}. In each of these lookups, only names that denote types or templates whose specializations are types are considered. -\enterexample +\begin{example} \begin{codeblock} struct A { }; namespace N { @@ -2184,7 +2184,7 @@ a.operator A(); // calls \tcode{N::A::operator N::A} } \end{codeblock} -\exitexample +\end{example} \rSec2[basic.lookup.udir]{Using-directives and namespace aliases} @@ -2299,7 +2299,7 @@ outside the innermost enclosing namespace scope, the block scope declaration declares that same entity and receives the linkage of the previous declaration. If there is more than one such matching entity, the program is ill-formed. Otherwise, if no matching -entity is found, the block scope entity receives external linkage.\enterexample +entity is found, the block scope entity receives external linkage.\begin{example} \begin{codeblock} static void f(); @@ -2319,13 +2319,13 @@ \tcode{\#1} ), the object with automatic storage duration and no linkage introduced by the declaration on line \tcode{\#2}, and the object with static storage duration and external linkage introduced by the -declaration on line \tcode{\#3}. \exitexample +declaration on line \tcode{\#3}. \end{example} \pnum When a block scope declaration of an entity with linkage is not found to refer to some other declaration, then that entity is a member of the innermost enclosing namespace. However such a declaration does not -introduce the member name in its namespace scope. \enterexample +introduce the member name in its namespace scope. \begin{example} \begin{codeblock} namespace X { @@ -2343,7 +2343,7 @@ void q() @\tcode{\{ /* ... */ \}}@ // some other, unrelated \tcode{q} \end{codeblock} -\exitexample +\end{example} \pnum \indextext{linkage!no}% @@ -2383,15 +2383,15 @@ \item the entity is not odr-used~(\ref{basic.def.odr}) or is defined in the same translation unit. \end{itemize} -\enternote In other words, a type without linkage contains a class or enumeration that +\begin{note} In other words, a type without linkage contains a class or enumeration that cannot be named outside its translation unit. An entity with external linkage declared using such a type could not correspond to any other entity in another translation unit of the program and thus must be defined in the translation unit if it is odr-used. Also note that classes with linkage may contain members whose types do not have linkage, and that typedef names are ignored in the determination -of whether a type has linkage. \exitnote +of whether a type has linkage. \end{note} -\enterexample +\begin{example} \begin{codeblock} template struct B { void g(T) { } @@ -2408,7 +2408,7 @@ i(ba, a); // OK } \end{codeblock} -\exitexample +\end{example} \pnum Two names that are the same (Clause~\ref{basic}) and that are declared @@ -2441,8 +2441,8 @@ identity does not require a diagnostic. \pnum -\enternote Linkage to non-\Cpp declarations can be achieved using a -\grammarterm{linkage-specification}~(\ref{dcl.link}). \exitnote% +\begin{note} Linkage to non-\Cpp declarations can be achieved using a +\grammarterm{linkage-specification}~(\ref{dcl.link}). \end{note}% \indextext{linkage|)} \rSec1[basic.start]{Start and termination} @@ -2455,11 +2455,11 @@ A program shall contain a global function called \tcode{main}, which is the designated start of the program. It is \impldef{defining \tcode{main} in freestanding environment} whether a program in a freestanding environment is required to define a \tcode{main} -function. \enternote In a freestanding environment, start-up and termination is +function. \begin{note} In a freestanding environment, start-up and termination is \impldef{start-up and termination in freestanding environment}; start-up contains the execution of constructors for objects of namespace scope with static storage duration; termination contains the execution of destructors for objects with static storage -duration. \exitnote +duration. \end{note} \pnum An implementation shall not predefine the \tcode{main} function. This @@ -2490,9 +2490,9 @@ s)~(\ref{multibyte.strings}) and \tcode{argv[0]} shall be the pointer to the initial character of a \ntmbs that represents the name used to invoke the program or \tcode{""}. The value of \tcode{argc} shall be -non-negative. The value of \tcode{argv[argc]} shall be 0. \enternote It +non-negative. The value of \tcode{argv[argc]} shall be 0. \begin{note} It is recommended that any further (optional) parameters be added after -\tcode{argv}. \exitnote +\tcode{argv}. \end{note} \pnum The function \tcode{main} shall not be used within @@ -2507,9 +2507,9 @@ declares a variable \tcode{main} at global scope or that declares the name \tcode{main} with C language linkage (in any namespace) is ill-formed. The name \tcode{main} is -not otherwise reserved. \enterexample member functions, classes, and +not otherwise reserved. \begin{example} member functions, classes, and enumerations can be called \tcode{main}, as can entities in other -namespaces. \exitexample +namespaces. \end{example} \pnum \indextext{\idxcode{exit}}% @@ -2550,7 +2550,7 @@ A \defn{constant initializer} for an object \tcode{o} is an expression that is a constant expression, except that it may also invoke \tcode{constexpr} constructors for \tcode{o} and its subobjects even if those objects are of non-literal class -types \enternote such a class may have a non-trivial destructor \exitnote. +types \begin{note} such a class may have a non-trivial destructor \end{note}. \defnx{Constant initialization}{constant initialization} is performed: \begin{itemize} @@ -2582,9 +2582,9 @@ \defn{static initialization}; all other initialization is \defn{dynamic initialization}. Static initialization shall be performed before any dynamic initialization takes place. -\enternote The dynamic initialization of non-local variables is described +\begin{note} The dynamic initialization of non-local variables is described in~\ref{basic.start.dynamic}; that of local static variables is described -in~\ref{stmt.dcl}. \exitnote +in~\ref{stmt.dcl}. \end{note} \pnum An implementation is permitted to perform the initialization of a @@ -2606,7 +2606,7 @@ \end{itemize} % \item -\enternote As a consequence, if the initialization of an object \tcode{obj1} refers to an +\begin{note} As a consequence, if the initialization of an object \tcode{obj1} refers to an object \tcode{obj2} of namespace scope potentially requiring dynamic initialization and defined later in the same translation unit, it is unspecified whether the value of \tcode{obj2} used will be the value of the fully initialized \tcode{obj2} (because \tcode{obj2} was statically @@ -2621,7 +2621,7 @@ // dynamically initialized, or \tcode{1.0} otherwise double d1 = fd(); // may be initialized statically or dynamically to \tcode{1.0} \end{codeblock} -\exitnote +\end{note} \rSec2[basic.start.dynamic]{Dynamic initialization of non-local variables} @@ -2632,8 +2632,8 @@ Dynamic initialization of a non-local variable with static storage duration is unordered if the variable is an implicitly or explicitly instantiated specialization, and otherwise is ordered -\enternote an explicitly specialized static data member or -variable template specialization has ordered initialization.\exitnote. +\begin{note} an explicitly specialized static data member or +variable template specialization has ordered initialization.\end{note}. Variables with ordered initialization defined within a single translation unit shall be initialized in the order of their definitions in the translation unit. If a program starts a thread~(\ref{thread.threads}), the subsequent @@ -2645,8 +2645,8 @@ a variable is unsequenced with respect to every other dynamic initialization. Otherwise, the unordered initialization of a variable is indeterminately sequenced with respect to every other dynamic initialization. -\enternote This definition permits initialization of a sequence of -ordered variables concurrently with another sequence. \exitnote +\begin{note} This definition permits initialization of a sequence of +ordered variables concurrently with another sequence. \end{note} \pnum \indextext{evaluation!unspecified order~of}% @@ -2660,7 +2660,7 @@ having initialization with side-effects must be initialized even if it is not odr-used (\ref{basic.def.odr},~\ref{basic.stc.static}).} -\enterexample +\begin{example} \begin{codeblock} // - File 1 - @@ -2695,7 +2695,7 @@ initialized before it is odr-used by the initialization of \tcode{a}, that is, before \tcode{A::A} is called. If, however, \tcode{a} is initialized at some point after the first statement of \tcode{main}, \tcode{b} will -be initialized prior to its use in \tcode{A::A}. \exitexample +be initialized prior to its use in \tcode{A::A}. \end{example} \pnum It is \impldef{dynamic initialization of thread-local objects before entry} @@ -2739,7 +2739,7 @@ If the completion of the constructor or dynamic initialization of an object with static storage duration is sequenced before that of another, the completion of the destructor of the second is sequenced before the initiation of the destructor of the first. -\enternote This definition permits concurrent destruction. \exitnote If an object is +\begin{note} This definition permits concurrent destruction. \end{note} If an object is initialized statically, the object is destroyed in the same order as if the object was dynamically initialized. For an object of array or class type, all subobjects of that object are destroyed before any block-scope @@ -2776,11 +2776,11 @@ handlers~(\ref{support.runtime}) that does not happen before~(\ref{intro.multithread}) completion of destruction of objects with static storage duration and execution of \tcode{std::atexit} registered functions~(\ref{support.start.term}), the program has -undefined behavior. \enternote If there is a use of an object with static storage +undefined behavior. \begin{note} If there is a use of an object with static storage duration that does not happen before the object's destruction, the program has undefined behavior. Terminating every thread before a call to \tcode{std::exit} or the exit from \tcode{main} is sufficient, but not necessary, to satisfy these requirements. These -requirements permit thread managers as static-storage-duration objects. \exitnote +requirements permit thread managers as static-storage-duration objects. \end{note} \pnum \indextext{\idxcode{abort}}% @@ -2842,9 +2842,9 @@ \pnum \indextext{object!\idxcode{local static}}% The keyword \tcode{static} can be used to declare a local variable with -static storage duration. \enternote \ref{stmt.dcl} describes the +static storage duration. \begin{note} \ref{stmt.dcl} describes the initialization of local \tcode{static} variables; \ref{basic.start.term} -describes the destruction of local \tcode{static} variables. \exitnote +describes the destruction of local \tcode{static} variables. \end{note} \pnum \indextext{member!\idxcode{class static}}% @@ -2876,9 +2876,9 @@ for these entities lasts until the block in which they are created exits. \pnum -\enternote +\begin{note} These variables are initialized and destroyed as described in~\ref{stmt.dcl}. -\exitnote +\end{note} \pnum If a variable with automatic storage duration has initialization or a destructor with side @@ -2925,7 +2925,7 @@ These implicit declarations introduce only the function names \tcode{operator} \tcode{new}, \tcode{operator} \tcode{new[]}, \tcode{op\-er\-a\-tor} \tcode{delete}, and \tcode{operator} -\tcode{delete[]}. \enternote The implicit declarations do not introduce +\tcode{delete[]}. \begin{note} The implicit declarations do not introduce the names \tcode{std}, \tcode{std\colcol{}size_t}, or any other names that the library uses to declare these names. Thus, a \grammarterm{new-expression}, @@ -2933,7 +2933,7 @@ these functions without including the header \tcode{} is well-formed. However, referring to \tcode{std} or \tcode{std::size_t} is ill-formed unless the name has been declared -by including the appropriate header. \exitnote Allocation and/or +by including the appropriate header. \end{note} Allocation and/or deallocation functions can also be declared and defined for any class~(\ref{class.free}). @@ -2992,11 +2992,11 @@ \pnum An allocation function that fails to allocate storage can invoke the currently installed new-handler function~(\ref{new.handler}), if any. -\enternote +\begin{note} \indextext{\idxcode{new_handler}}% A program-supplied allocation function can obtain the address of the currently installed \tcode{new_handler} using the -\tcode{std::get_new_handler} function~(\ref{set.new.handler}). \exitnote +\tcode{std::get_new_handler} function~(\ref{set.new.handler}). \end{note} If an allocation function that has a non-throwing exception specification~(\ref{except.spec}) fails to allocate storage, it shall return a null pointer. Any other @@ -3009,13 +3009,13 @@ A global allocation function is only called as the result of a new expression~(\ref{expr.new}), or called directly using the function call syntax~(\ref{expr.call}), or called indirectly through calls to the -functions in the \Cpp standard library. \enternote In particular, a +functions in the \Cpp standard library. \begin{note} In particular, a global allocation function is not called to allocate storage for objects with static storage duration~(\ref{basic.stc.static}), for objects or references with thread storage duration~(\ref{basic.stc.thread}), for objects of type \tcode{std::type_info}~(\ref{expr.typeid}), or for an exception object~(\ref{except.throw}). -\exitnote +\end{note} \rSec3[basic.stc.dynamic.deallocation]{Deallocation functions} @@ -3057,9 +3057,9 @@ \tcode{std::size_t}, then this function is a usual deallocation function. A deallocation function can be an instance of a function template. Neither the first parameter nor the return type shall depend -on a template parameter. \enternote That is, a deallocation function +on a template parameter. \begin{note} That is, a deallocation function template shall have a first parameter of type \tcode{void*} and a return -type of \tcode{void} (as specified above). \exitnote A deallocation +type of \tcode{void} (as specified above). \end{note} A deallocation function template shall have two or more function parameters. A template instance is never a usual deallocation function, regardless of its signature. @@ -3179,11 +3179,11 @@ storage duration that is not a safely-derived pointer value is an invalid pointer value unless the referenced complete object has previously been declared -reachable~(\ref{util.dynamic.safety}). \enternote +reachable~(\ref{util.dynamic.safety}). \begin{note} the effect of using an invalid pointer value (including passing it to a deallocation function) is undefined, see~\ref{basic.stc.dynamic.deallocation}. This is true even if the unsafely-derived pointer value might compare equal to -some safely-derived pointer value. \exitnote It is implementation +some safely-derived pointer value. \end{note} It is implementation defined\indeximpldef{whether an implementation has relaxed or strict pointer safety} whether an implementation has relaxed or strict pointer safety.% \indextext{pointer!safely-derived|)}% @@ -3206,8 +3206,8 @@ object or reference. An object is said to have \term{non-vacuous initialization} if it is of a class or aggregate type and it or one of its subobjects is initialized by a constructor -other than a trivial default constructor. \enternote initialization by a -trivial copy/move constructor is non-vacuous initialization. \exitnote +other than a trivial default constructor. \begin{note} initialization by a +trivial copy/move constructor is non-vacuous initialization. \end{note} The lifetime of an object of type \tcode{T} begins when: \begin{itemize} @@ -3231,12 +3231,12 @@ The lifetime of a reference ends as if it were a scalar object. \pnum -\enternote \ref{class.base.init} -describes the lifetime of base and member subobjects. \exitnote +\begin{note} \ref{class.base.init} +describes the lifetime of base and member subobjects. \end{note} \pnum The properties ascribed to objects and references throughout this International -Standard apply for a given object or reference only during its lifetime. \enternote +Standard apply for a given object or reference only during its lifetime. \begin{note} In particular, before the lifetime of an object starts and after its lifetime ends there are significant restrictions on the use of the object, as described below, in~\ref{class.base.init} and @@ -3244,7 +3244,7 @@ and destruction might not be the same as the behavior of an object whose lifetime has started and not ended. \ref{class.base.init} and~\ref{class.cdtor} describe the behavior of objects during the -construction and destruction phases. \exitnote +construction and destruction phases. \end{note} \pnum A program may end the lifetime of any object by reusing the storage @@ -3293,7 +3293,7 @@ \tcode{char} or \term{cv} \tcode{unsigned char}, or \item the pointer is used as the operand of a -\tcode{dynamic_cast}~(\ref{expr.dynamic.cast}). \enterexample +\tcode{dynamic_cast}~(\ref{expr.dynamic.cast}). \begin{example} \begin{codeblock} #include @@ -3322,7 +3322,7 @@ pb->f(); // undefined behavior, lifetime of \tcode{*pb} has ended } \end{codeblock} -\exitexample +\end{example} \end{itemize} \pnum @@ -3374,7 +3374,7 @@ \item the original object was a most derived object~(\ref{intro.object}) of type \tcode{T} and the new object is a most derived object of type -\tcode{T} (that is, they are not base class subobjects). \enterexample +\tcode{T} (that is, they are not base class subobjects). \begin{example} \begin{codeblock} struct C { @@ -3398,7 +3398,7 @@ c1.f(); // well-defined; \tcode{c1} refers to a new object of type \tcode{C} \end{codeblock} -\exitexample +\end{example} \end{itemize} \pnum @@ -3414,7 +3414,7 @@ the program must ensure that an object of the original type occupies that same storage location when the implicit destructor call takes place; otherwise the behavior of the program is undefined. This is true -even if the block is exited with an exception. \enterexample +even if the block is exited with an exception. \begin{example} \begin{codeblock} class T { }; @@ -3427,13 +3427,13 @@ new (&b) T; } // undefined behavior at block exit \end{codeblock} -\exitexample +\end{example} \pnum Creating a new object at the storage location that a \tcode{const} object with static, thread, or automatic storage duration occupies or, at the storage location that such a \tcode{const} object used to occupy before -its lifetime ended results in undefined behavior. \enterexample +its lifetime ended results in undefined behavior. \begin{example} \begin{codeblock} struct B { @@ -3448,20 +3448,20 @@ new (const_cast(&b)) const B; // undefined behavior } \end{codeblock} -\exitexample +\end{example} \pnum In this section, ``before'' and ``after'' refer to the ``happens before'' -relation~(\ref{intro.multithread}). \enternote Therefore, undefined behavior results +relation~(\ref{intro.multithread}). \begin{note} Therefore, undefined behavior results if an object that is being constructed in one thread is referenced from another -thread without adequate synchronization. \exitnote% +thread without adequate synchronization. \end{note}% \indextext{object~lifetime|)} \rSec1[basic.types]{Types}% \indextext{type|(} \pnum -\enternote +\begin{note} \ref{basic.types} and the subclauses thereof impose requirements on implementations regarding the representation of types. @@ -3469,7 +3469,7 @@ Types describe objects (\ref{intro.object}), references (\ref{dcl.ref}), or functions (\ref{dcl.fct}). -\exitnote +\end{note} \pnum \indextext{object!byte~copying~and|(}% @@ -3482,7 +3482,7 @@ functions~(\ref{headers}) \tcode{std::memcpy} or \tcode{std::memmove}.} If the content of the array of \tcode{char} or \tcode{unsigned} \tcode{char} is copied back into the object, the object shall -subsequently hold its original value. \enterexample +subsequently hold its original value. \begin{example} \begin{codeblock} #define N sizeof(T) @@ -3493,7 +3493,7 @@ std::memcpy(&obj, buf, N); // at this point, each subobject of \tcode{obj} of scalar type // holds its original value \end{codeblock} -\exitexample +\end{example} \pnum For any trivially copyable type \tcode{T}, if two pointers to \tcode{T} point to @@ -3503,7 +3503,7 @@ \tcode{obj1} are copied into \tcode{obj2},\footnote{By using, for example, the library functions~(\ref{headers}) \tcode{std::memcpy} or \tcode{std::memmove}.} \tcode{obj2} shall subsequently hold the same value as -\tcode{obj1}. \enterexample +\tcode{obj1}. \begin{example} \begin{codeblock} T* t1p; @@ -3513,7 +3513,7 @@ // at this point, every subobject of trivially copyable type in \tcode{*t1p} contains // the same value as the corresponding subobject in \tcode{*t2p} \end{codeblock} -\exitexample% +\end{example}% \indextext{object!byte~copying~and|)} \pnum @@ -3559,7 +3559,7 @@ those two points (``array of unknown bound of \tcode{T}'' and ``array of \tcode{N} \tcode{T}'') are different types. The type of a pointer to array of unknown size, or of a type defined by a \tcode{typedef} declaration to -be an array of unknown size, cannot be completed. \enterexample +be an array of unknown size, cannot be completed. \begin{example} \indextext{type!example~of incomplete}% \begin{codeblock} @@ -3587,11 +3587,11 @@ arrp++; // ill-formed: \tcode{UNKA} can't be completed } \end{codeblock} -\exitexample +\end{example} \pnum -\enternote The rules for declarations and expressions describe in which -contexts incomplete types are prohibited. \exitnote +\begin{note} The rules for declarations and expressions describe in which +contexts incomplete types are prohibited. \end{note} \pnum \indextext{object~type}% @@ -3805,8 +3805,8 @@ Standard as ``undefined,'' such as by examining the value of an uninitialized automatic object, might cause it to behave as if it is neither \tcode{true} nor \tcode{false}.} -\enternote There are no \tcode{signed}, \tcode{unsigned}, \tcode{short}, -or \tcode{long bool} types or values. \exitnote Values of type +\begin{note} There are no \tcode{signed}, \tcode{unsigned}, \tcode{short}, +or \tcode{long bool} types or values. \end{note} Values of type \tcode{bool} participate in integral promotions~(\ref{conv.prom}). \pnum @@ -3826,9 +3826,9 @@ begin with 1, and are multiplied by successive integral power of 2, except perhaps for the bit with the highest position. (Adapted from the \doccite{American National Dictionary for Information Processing Systems}.)} -\enterexample this International Standard permits two's complement, +\begin{example} this International Standard permits two's complement, ones' complement and signed magnitude representations for integral types. -\exitexample +\end{example} \pnum \indextext{floating~point~type}% @@ -3849,10 +3849,10 @@ floating-point types}. \indextext{floating~point~type!implementation-defined}% \indextext{type!arithmetic}% -\enternote +\begin{note} This International Standard imposes no requirements on the accuracy of floating-point operations; see also~\ref{limits}. -\exitnote +\end{note} \term{Integral} and \term{floating} types are collectively called \term{arithmetic} types. \indextext{\idxcode{numeric_limits}!specializations for arithmetic types}% @@ -3884,10 +3884,10 @@ \tcode{sizeof(std::nullptr_t)} shall be equal to \tcode{sizeof(void*)}. \pnum -\enternote +\begin{note} Even if the implementation defines two or more basic types to have the same value representation, they are nevertheless different types. -\exitnote +\end{note} \rSec2[basic.compound]{Compound types} @@ -3955,14 +3955,14 @@ \pnum \indextext{terminology!pointer}% The type of a pointer to \cv\ \tcode{void} or a pointer to an object type is -called an \defn{object pointer type}. \enternote A pointer to \tcode{void} +called an \defn{object pointer type}. \begin{note} A pointer to \tcode{void} does not have a pointer-to-object type, however, because \tcode{void} is not -an object type. \exitnote The type of a pointer that can designate a function +an object type. \end{note} The type of a pointer that can designate a function is called a \defn{function pointer type}. A pointer to objects of type \tcode{T} is referred to as a ``pointer to -\tcode{T}''. \enterexample a pointer to an object of type \tcode{int} is +\tcode{T}''. \begin{example} a pointer to an object of type \tcode{int} is referred to as ``pointer to \tcode{int} '' and a pointer to an object of -class \tcode{X} is called a ``pointer to \tcode{X}''. \exitexample +class \tcode{X} is called a ``pointer to \tcode{X}''. \end{example} Except for pointers to static members, text referring to ``pointers'' does not apply to pointers to members. Pointers to incomplete types are allowed although there are restrictions on what can be done with @@ -3974,22 +3974,22 @@ object of type \tcode{T} is located at an address \tcode{A}, a pointer of type \term{cv} \tcode{T*} whose value is the address \tcode{A} is said to \term{point to} that object, regardless of how the value was -obtained. \enternote For instance, the address one past the end of an +obtained. \begin{note} For instance, the address one past the end of an array~(\ref{expr.add}) would be considered to point to an unrelated object of the array's element type that might be located at that address. There are further restrictions on pointers to objects with dynamic storage -duration; see~\ref{basic.stc.dynamic.safety}. \exitnote The value representation of +duration; see~\ref{basic.stc.dynamic.safety}. \end{note} The value representation of pointer types is \impldef{value representation of pointer types}. Pointers to layout-compatible types shall have the same value representation and alignment requirements~(\ref{basic.align}). -\enternote Pointers to over-aligned types~(\ref{basic.align}) have no special +\begin{note} Pointers to over-aligned types~(\ref{basic.align}) have no special representation, but their range of valid values is restricted by the extended alignment requirement. This International Standard specifies only two ways of obtaining such a pointer: taking the address of a valid object with an over-aligned type, and using one of the runtime pointer alignment functions. An implementation may provide other means of obtaining a valid pointer value -for an over-aligned type.\exitnote +for an over-aligned type.\end{note} \pnum \indextext{pointer|seealso{\tcode{void*}}}% @@ -4080,7 +4080,7 @@ \indextext{cv-qualifier!top-level} For a type \cv\ \tcode{T}, the \term{top-level cv-qualifiers} of that type are those denoted by \cv. -\enterexample +\begin{example} The type corresponding to the \grammarterm{type-id} \tcode{const int\&} has no top-level cv-qualifiers. @@ -4091,7 +4091,7 @@ the type corresponding to the \grammarterm{type-id} \tcode{void (C::* volatile)(int) const} has the top-level cv-qualifier \tcode{volatile}. -\exitexample +\end{example} \pnum Cv-qualifiers applied to an array @@ -4101,7 +4101,7 @@ are cv-qualified is also considered to have the same cv-qualifications as its elements.% \indextext{type|)} -\enterexample +\begin{example} \begin{codeblock} typedef char CA[5]; typedef const char CC; @@ -4111,7 +4111,7 @@ The type of both \tcode{arr1} and \tcode{arr2} is ``array of 5 \tcode{const char}'', and the array type is considered to be \tcode{const}-qualified. -\exitexample +\end{example} \rSec1[basic.lval]{Lvalues and rvalues} \pnum @@ -4126,16 +4126,16 @@ \begin{itemize} \item An \defn{lvalue} (so called, historically, because lvalues could appear on the left-hand side of an assignment expression) designates a function or an object. -\enterexample If \tcode{E} is an expression of pointer type, then \tcode{*E} is +\begin{example} If \tcode{E} is an expression of pointer type, then \tcode{*E} is an lvalue expression referring to the object or function to which \tcode{E} points. As another example, the result of calling a function whose return type is an -lvalue reference is an lvalue. \exitexample +lvalue reference is an lvalue. \end{example} \item An \defn{xvalue} (an ``eXpiring'' value) also refers to an object, usually near the end of its lifetime (so that its resources may be moved, for example). Certain kinds of expressions involving rvalue references~(\ref{dcl.ref}) yield xvalues. -\enterexample The result of calling a function whose return type is an rvalue reference -to an object type is an xvalue~(\ref{expr.call}). \exitexample +\begin{example} The result of calling a function whose return type is an rvalue reference +to an object type is an xvalue~(\ref{expr.call}). \end{example} \item A \defn{glvalue} (``generalized'' lvalue) is an lvalue or an xvalue. @@ -4145,32 +4145,32 @@ associated with an object. \item A \defn{prvalue} (``pure'' rvalue) is an rvalue that is not an xvalue. -\enterexample The result of calling a function whose return type is not a reference +\begin{example} The result of calling a function whose return type is not a reference is a prvalue. The value of a literal such as \tcode{12}, \tcode{7.3e5}, or \tcode{true} -is also a prvalue. \exitexample +is also a prvalue. \end{example} \end{itemize} Every expression belongs to exactly one of the fundamental classifications in this taxonomy: lvalue, xvalue, or prvalue. This property of an expression is called -its \defn{value category}. \enternote The discussion of each built-in operator in +its \defn{value category}. \begin{note} The discussion of each built-in operator in Clause~\ref{expr} indicates the category of the value it yields and the value categories of the operands it expects. For example, the built-in assignment operators expect that the left operand is an lvalue and that the right operand is a prvalue and yield an lvalue as the result. User-defined operators are functions, and the categories of -values they expect and yield are determined by their parameter and return types. \exitnote +values they expect and yield are determined by their parameter and return types. \end{note} \pnum Whenever a glvalue appears in a context where a prvalue is expected, the glvalue is converted to a prvalue; see~\ref{conv.lval}, \ref{conv.array}, and~\ref{conv.func}. -\enternote +\begin{note} An attempt to bind an rvalue reference to an lvalue is not such a context; see~\ref{dcl.init.ref}. -\exitnote -\enternote +\end{note} +\begin{note} There are no prvalue bit-fields; if a bit-field is converted to a prvalue~(\ref{conv.lval}), a prvalue of the type of the bit-field is created, which might then be promoted~(\ref{conv.prom}). -\exitnote +\end{note} \pnum The discussion of reference initialization in~\ref{dcl.init.ref} and of @@ -4181,18 +4181,18 @@ Unless otherwise indicated~(\ref{expr.call}), a prvalue shall always have complete type or the \tcode{void} type. A glvalue shall not have type \cv \tcode{void}. -\enternote +\begin{note} A glvalue may have complete or incomplete non-\tcode{void} type. Class and array prvalues can have cv-qualified types; other prvalues always have cv-unqualified types. See Clause~\ref{expr}. -\exitnote +\end{note} \pnum An lvalue for an object is necessary in order to modify the object except that an rvalue of class type can also be used to modify its -referent under certain circumstances. \enterexample a member function +referent under certain circumstances. \begin{example} a member function called for an object~(\ref{class.mfct}) can modify the object. -\exitexample +\end{example} \pnum Functions cannot be modified, but pointers to functions can be @@ -4265,7 +4265,7 @@ all contexts, which is equal to \tcode{alignof(std::max_align_t)}~(\ref{support.types}). The alignment required for a type might be different when it is used as the type -of a complete object and when it is used as the type of a subobject. \enterexample +of a complete object and when it is used as the type of a subobject. \begin{example} \begin{codeblock} struct B { long double d; }; struct D : virtual B { char c; }; @@ -4276,7 +4276,7 @@ If \tcode{D} appears as a subobject of another object that also has \tcode{B} as a virtual base class, the \tcode{B} subobject might be part of a different subobject, reducing the alignment requirements on the \tcode{D} subobject. -\exitexample The result of the \tcode{alignof} operator reflects the alignment +\end{example} The result of the \tcode{alignof} operator reflects the alignment requirement of the type in the complete-object case. \pnum @@ -4288,10 +4288,10 @@ greater than \tcode{alignof(std::max_align_t)}. It is implementation-defined whether any extended alignments are supported and the contexts in which they are supported~(\ref{dcl.align}). A type having an extended alignment -requirement is an \grammarterm{over-aligned type}. \enternote +requirement is an \grammarterm{over-aligned type}. \begin{note} every over-aligned type is or contains a class type to which extended alignment applies (possibly through a non-static data member). -\exitnote +\end{note} \pnum Alignments are represented as values of the type \tcode{std::size_t}. @@ -4312,8 +4312,8 @@ \tcode{alignof} expression~(\ref{expr.alignof}). Furthermore, the narrow character types~(\ref{basic.fundamental}) shall have the weakest alignment requirement. -\enternote This enables the narrow character types to be used as the -underlying type for an aligned memory area~(\ref{dcl.align}).\exitnote +\begin{note} This enables the narrow character types to be used as the +underlying type for an aligned memory area~(\ref{dcl.align}).\end{note} \pnum Comparing alignments is meaningful and provides the obvious results: @@ -4325,10 +4325,10 @@ \end{itemize} \pnum -\enternote The runtime pointer alignment function~(\ref{ptr.align}) +\begin{note} The runtime pointer alignment function~(\ref{ptr.align}) can be used to obtain an aligned pointer within a buffer; the aligned-storage templates in the library~(\ref{meta.trans.other}) can be used to obtain aligned storage. -\exitnote +\end{note} \pnum If a request for a specific extended alignment in a specific context is not diff --git a/source/classes.tex b/source/classes.tex index 5ebed0c136..c97f5b83bd 100644 --- a/source/classes.tex +++ b/source/classes.tex @@ -58,8 +58,8 @@ A \grammarterm{class-specifier} whose \grammarterm{class-head} omits the -\grammarterm{class-head-name} defines an unnamed class. \enternote An unnamed class thus can't -be \tcode{final}. \exitnote +\grammarterm{class-head-name} defines an unnamed class. \begin{note} An unnamed class thus can't +be \tcode{final}. \end{note} \pnum A \grammarterm{class-name} is inserted into the scope in which it is @@ -86,7 +86,7 @@ (Clause~\ref{class.derived}), the program is ill-formed. Whenever a \grammarterm{class-key} is followed by a \grammarterm{class-head-name}, the \grammarterm{identifier} \tcode{final}, and a colon or left brace, \tcode{final} is -interpreted as a \grammarterm{class-virt-specifier}. \enterexample +interpreted as a \grammarterm{class-virt-specifier}. \begin{example} \begin{codeblock} struct A; struct A final {}; // OK: definition of \tcode{struct A}, @@ -98,17 +98,17 @@ // not declaration of a bit-field member \tcode{final} }; \end{codeblock} -\exitexample +\end{example} \pnum Complete objects and member subobjects of class type shall have nonzero size.\footnote{Base class subobjects are not so constrained.} -\enternote +\begin{note} Class objects can be assigned, passed as arguments to functions, and returned by functions (except objects of classes for which copying or moving has been restricted; see~\ref{class.copy}). Other plausible operators, such as equality comparison, can be defined by the user; see~\ref{over.oper}. -\exitnote +\end{note} \pnum \indextext{\idxcode{struct}!\tcode{class}~versus}% @@ -118,9 +118,9 @@ \tcode{union}; \indextext{access control!\idxcode{union} default member}% it holds at most one data member at a time~(\ref{class.union}). -\enternote +\begin{note} Aggregates of class type are described in~\ref{dcl.init.aggr}. -\exitnote +\end{note} \indextext{class!trivial}% \indextext{trivial~class}% @@ -141,8 +141,8 @@ has one or more default constructors~(\ref{class.ctor}), all of which are either trivial or deleted and at least one of which is not deleted. -\enternote In particular, a trivially copyable or trivial class does not have -virtual functions or virtual base classes.\exitnote +\begin{note} In particular, a trivially copyable or trivial class does not have +virtual functions or virtual base classes.\end{note} \indextext{class!standard-layout}% \indextext{standard-layout~class}% @@ -193,11 +193,11 @@ \item If \tcode{X} is a non-class, non-array type, the set $M(\mathtt{X})$ is empty. \end{itemize} -\enternote $M(\mathtt{X})$ is the set of the types of all non-base-class subobjects +\begin{note} $M(\mathtt{X})$ is the set of the types of all non-base-class subobjects that are guaranteed in a standard-layout class to be at a zero offset -in \tcode{X}. \exitnote +in \tcode{X}. \end{note} -\enterexample +\begin{example} \begin{codeblock} struct B { int i; }; // standard-layout class struct C : B { }; // standard-layout class @@ -209,7 +209,7 @@ struct T : Q { }; struct U : S, T { }; // not a standard-layout class \end{codeblock} -\exitexample +\end{example} \indextext{struct!standard-layout}% \indextext{standard-layout~struct}% @@ -224,9 +224,9 @@ \grammarterm{class-key} \tcode{union}. \pnum -\enternote Standard-layout classes are useful for communicating with +\begin{note} Standard-layout classes are useful for communicating with code written in other programming languages. Their layout is specified -in~\ref{class.mem}.\exitnote +in~\ref{class.mem}.\end{note} \pnum \indextext{POD struct}\indextext{POD class}\indextext{POD union}% @@ -239,7 +239,7 @@ union (or array of such types). A \term{POD class} is a class that is either a POD struct or a POD union. -\enterexample +\begin{example} \begin{codeblock} struct N { // neither trivial nor standard-layout int i; @@ -264,7 +264,7 @@ int j; }; \end{codeblock} -\exitexample +\end{example} \pnum If a \grammarterm{class-head-name} contains a \grammarterm{nested-name-specifier}, @@ -287,7 +287,7 @@ \pnum A class definition introduces a new type. -\enterexample +\begin{example} \begin{codeblock} struct X { int a; }; @@ -321,7 +321,7 @@ \end{codeblock} is ill-formed because it defines \tcode{S} twice. -\exitexample +\end{example} \pnum \indextext{definition!scope~of class}% @@ -335,7 +335,7 @@ declared, then when both declarations are in scope, the class can be referred to only using an \grammarterm{elaborated-type-specifier}~(\ref{basic.lookup.elab}). -\enterexample +\begin{example} \begin{codeblock} struct stat { @@ -353,14 +353,14 @@ stat(ps); // call \tcode{stat()} } \end{codeblock} -\exitexample +\end{example} \indextext{class~name!elaborated}% \indextext{declaration!forward class}% A \grammarterm{declaration} consisting solely of \grammarterm{class-key identifier;} is either a redeclaration of the name in the current scope or a forward declaration of the identifier as a class name. It introduces the class name into the current scope. -\enterexample +\begin{example} \begin{codeblock} struct s { int a; }; @@ -373,11 +373,11 @@ struct s; // redeclaration, has no effect } \end{codeblock} -\exitexample -\enternote +\end{example} +\begin{note} Such declarations allow definition of classes that refer to each other. \indextext{example!friend}% -\enterexample +\begin{example} \begin{codeblock} class Vector; @@ -395,19 +395,19 @@ Declaration of \tcode{friend}s is described in~\ref{class.friend}, operator functions in~\ref{over.oper}. -\exitexample -\exitnote +\end{example} +\end{note} \pnum \indextext{class~name!elaborated}% \indextext{elaborated~type~specifier|see{class name, elaborated}}% -\enternote +\begin{note} An \grammarterm{elaborated-type-specifier}~(\ref{dcl.type.elab}) can also be used as a \grammarterm{type-specifier} as part of a declaration. It differs from a class declaration in that if a class of the elaborated name is in scope the elaborated name will refer to it. -\exitnote -\enterexample +\end{note} +\begin{example} \begin{codeblock} struct s { int a; }; @@ -417,11 +417,11 @@ p->a = s; // parameter \tcode{s} } \end{codeblock} -\exitexample +\end{example} \pnum \indextext{class~name!point~of declaration}% -\enternote +\begin{note} The declaration of a class name takes effect immediately after the \grammarterm{identifier} is seen in the class definition or \grammarterm{elaborated-type-specifier}. For example, @@ -434,7 +434,7 @@ it as the name of a pointer to an object of that class. This means that the elaborated form \tcode{class} \tcode{A} must be used to refer to the class. Such artistry with names can be confusing and is best avoided. -\exitnote +\end{note} \pnum \indextext{class~name!\idxcode{typedef}}% @@ -503,8 +503,8 @@ Members of a class are data members, member functions~(\ref{class.mfct}), nested types, and enumerators. Data members and member functions are static or non-static; -see~\ref{class.static}. \enternote A non-static data member of non-reference -type is a member subobject of a class object~(\ref{intro.object}).\exitnote +see~\ref{class.static}. \begin{note} A non-static data member of non-reference +type is a member subobject of a class object~(\ref{intro.object}).\end{note} Nested types are classes~(\ref{class.name},~\ref{class.nest}) and enumerations~(\ref{dcl.enum}) defined in the class, and arbitrary types declared as members by use of a typedef declaration~(\ref{dcl.typedef}). @@ -538,10 +538,10 @@ \grammarterm{member-specification}. \pnum -\enternote +\begin{note} A single name can denote several function members provided their types are sufficiently different (Clause~\ref{over}). -\exitnote +\end{note} \pnum In a \grammarterm{member-declarator}, @@ -550,7 +550,7 @@ if the \grammarterm{declarator-id} has function type, otherwise it is interpreted as introducing a \grammarterm{brace-or-equal-initializer}. -\enterexample +\begin{example} \begin{codeblock} struct S { using T = void(); @@ -558,7 +558,7 @@ virtual T f = 0; // OK: \grammarterm{pure-specifier} }; \end{codeblock} -\exitexample +\end{example} \pnum A \grammarterm{brace-or-equal-initializer} shall appear only in the @@ -609,21 +609,21 @@ reference to an object of class \tcode{C}. \pnum -\enternote +\begin{note} See~\ref{expr.prim} for restrictions on the use of non-static data members and non-static member functions. -\exitnote +\end{note} \pnum -\enternote +\begin{note} The type of a non-static member function is an ordinary function type, and the type of a non-static data member is an ordinary object type. There are no special member function types or data member types. -\exitnote +\end{note} \pnum \indextext{example!class~definition}% -\enterexample +\begin{example} A simple example of a class definition is \begin{codeblock} @@ -649,7 +649,7 @@ \tcode{s.left} refers to the \tcode{left} subtree pointer of the object \tcode{s}; and \tcode{s.right->tword[0]} refers to the initial character of the \tcode{tword} member of the \tcode{right} subtree of \tcode{s}. -\exitexample +\end{example} \pnum \indextext{layout!class~object}% @@ -674,10 +674,10 @@ \item every static data member of class \tcode{T}; \item every member function of class \tcode{T} -\enternote +\begin{note} This restriction does not apply to constructors, which do not have names~(\ref{class.ctor}) -\exitnote; +\end{note}; \item every member of class \tcode{T} that is itself a type; @@ -702,7 +702,7 @@ such entity in each of the structs, such that corresponding entities have layout-compatible types and either neither entity is a bit-field or both are bit-fields with the same width. -\enterexample +\begin{example} \begin{codeblock} struct A { int a; char b; }; struct B { const int b1; volatile char b2; }; @@ -714,7 +714,7 @@ of either class. The common initial sequence of \tcode{A} and \tcode{C} and of \tcode{A} and \tcode{D} comprises the first member in each case. The common initial sequence of \tcode{A} and \tcode{E} is empty. -\exitexample +\end{example} \pnum Two standard-layout struct (Clause~\ref{class}) types are layout-compatible if @@ -732,19 +732,19 @@ of struct type \tcode{T1}, it is permitted to read a non-static data member \tcode{m} of another union member of struct type \tcode{T2} provided \tcode{m} is part of the common initial sequence of \tcode{T1} and \tcode{T2}. -\enternote +\begin{note} Reading a volatile object through a non-volatile glvalue has undefined behavior (\ref{dcl.type.cv}). -\exitnote +\end{note} \pnum If a standard-layout class object has any non-static data members, its address is the same as the address of its first non-static data member. Otherwise, its address is the same as the address of its first base class subobject (if any). -\enternote +\begin{note} There might therefore be unnamed padding within a standard-layout struct object, but not at its beginning, as necessary to achieve appropriate alignment. -\exitnote +\end{note} \rSec1[class.mfct]{Member functions}% \indextext{member function!class} @@ -778,11 +778,11 @@ also be defined outside of its class definition provided either its declaration in the class definition or its definition outside of the class definition declares the function as \tcode{inline}. -\enternote +\begin{note} Member functions of a class in namespace scope have the linkage of that class. Member functions of a local class~(\ref{class.local}) have no linkage. See~\ref{basic.link}. -\exitnote +\end{note} \pnum There shall be at most one definition of a non-inline member function in @@ -795,13 +795,13 @@ If the definition of a member function is lexically outside its class definition, the member function name shall be qualified by its class name using the \tcode{::} operator. -\enternote +\begin{note} A name used in a member function definition (that is, in the \grammarterm{parameter-declaration-clause} including the default arguments~(\ref{dcl.fct.default}) or in the member function body) is looked up as described in~\ref{basic.lookup}. -\exitnote -\enterexample +\end{note} +\begin{example} \begin{codeblock} struct X { @@ -819,7 +819,7 @@ typedef member \tcode{T} declared in class \tcode{X} and the default argument \tcode{count} refers to the static data member \tcode{count} declared in class \tcode{X}. -\exitexample +\end{example} \pnum A \tcode{static} local variable in a member function always refers to @@ -834,7 +834,7 @@ definition, if they are defined at all. \pnum -\enternote +\begin{note} A member function can be declared (but not defined) using a typedef for a function type. The resulting member function has exactly the same type as it would have if the function declarator were provided explicitly, @@ -854,7 +854,7 @@ \end{codeblock} Also see~\ref{temp.arg}. -\exitnote +\end{note} \rSec2[class.mfct.non-static]{Nonstatic member functions}% \indextext{member function!nonstatic} @@ -891,10 +891,10 @@ member access expression~(\ref{expr.ref}) using \tcode{(*this)}~(\ref{class.this}) as the \grammarterm{postfix-expression} to the left of the \tcode{.} operator. -\enternote +\begin{note} If \tcode{C} is not \tcode{X} or a base class of \tcode{X}, the class member access expression is ill-formed. -\exitnote +\end{note} Similarly during name lookup, when an \grammarterm{unqualified-id}~(\ref{expr.prim}) used in the definition of a member function for class \tcode{X} resolves to a \tcode{static} member, @@ -905,7 +905,7 @@ These transformations do not apply in the template definition context~(\ref{temp.dep.type}). \indextext{example!member~function}% -\enterexample +\begin{example} \begin{codeblock} struct tnode { @@ -939,7 +939,7 @@ to \tcode{n2.tword}. The functions \tcode{strlen}, \tcode{perror}, and \tcode{strcpy} are not members of the class \tcode{tnode} and should be declared elsewhere.\footnote{See, for example, \tcode{}~(\ref{c.strings}).} -\exitexample +\end{example} \pnum A non-static member function may be declared \tcode{const}, @@ -951,7 +951,7 @@ declared \tcode{volatile} is a \term{volatile} member function and a member function declared \tcode{const} \tcode{volatile} is a \term{const volatile} member function. -\enterexample +\begin{example} \begin{codeblock} struct X { @@ -962,7 +962,7 @@ \tcode{X::g} is a \tcode{const} member function and \tcode{X::h} is a \tcode{const} \tcode{volatile} member function. -\exitexample +\end{example} \pnum A non-static member function may be declared with a \grammarterm{ref-qualifier}~(\ref{dcl.fct}); see~\ref{over.match.funcs}. @@ -992,9 +992,9 @@ is declared \tcode{const} \tcode{volatile}, the type of \tcode{this} is \tcode{const} \tcode{volatile} \tcode{X*}. \indextext{member function!\idxcode{const}}% -\enternote thus in a \tcode{const} member function, the object for which the function is -called is accessed through a \tcode{const} access path. \exitnote -\enterexample +\begin{note} thus in a \tcode{const} member function, the object for which the function is +called is accessed through a \tcode{const} access path. \end{note} +\begin{example} \begin{codeblock} struct s { @@ -1012,7 +1012,7 @@ called. This is not allowed in a \tcode{const} member function because \tcode{this} is a pointer to \tcode{const}; that is, \tcode{*this} has \tcode{const} type. -\exitexample +\end{example} \pnum Similarly, \tcode{volatile} semantics~(\ref{dcl.type.cv}) apply in @@ -1023,7 +1023,7 @@ A \grammarterm{cv-qualified} member function can be called on an object-expression~(\ref{expr.ref}) only if the object-expression is as cv-qualified or less-cv-qualified than the member function. -\enterexample +\begin{example} \begin{codeblock} void k(s& x, const s& y) { @@ -1037,7 +1037,7 @@ The call \tcode{y.g()} is ill-formed because \tcode{y} is \tcode{const} and \tcode{s::g()} is a non-\tcode{const} member function, that is, \tcode{s::g()} is less-qualified than the object-expression \tcode{y}. -\exitexample +\end{example} \pnum \indextext{\idxcode{const}!constructor~and}% @@ -1046,10 +1046,10 @@ \indextext{\idxcode{volatile}!destructor~and}% Constructors~(\ref{class.ctor}) and destructors~(\ref{class.dtor}) shall not be declared \tcode{const}, \tcode{volatile} or \tcode{const} -\tcode{volatile}. \enternote However, these functions can be invoked to +\tcode{volatile}. \begin{note} However, these functions can be invoked to create and destroy objects with cv-qualified types, see~(\ref{class.ctor}) and~(\ref{class.dtor}). -\exitnote +\end{note} \rSec1[class.static]{Static members}% \indextext{member!static}% @@ -1066,7 +1066,7 @@ refer to a \tcode{static} member. A \tcode{static} member may be referred to using the class member access syntax, in which case the object expression is evaluated. -\enterexample +\begin{example} \begin{codeblock} struct process { @@ -1079,7 +1079,7 @@ g().reschedule(); // \tcode{g()} is called } \end{codeblock} -\exitexample +\end{example} \pnum A \tcode{static} member may be referred to directly in the scope of its @@ -1088,7 +1088,7 @@ as if a \grammarterm{qualified-id} expression was used, with the \grammarterm{nested-name-specifier} of the \grammarterm{qualified-id} naming the class scope from which the static member is referenced. -\enterexample +\begin{example} \begin{codeblock} int g(); @@ -1100,7 +1100,7 @@ }; int Y::i = g(); // equivalent to \tcode{Y::g();} \end{codeblock} -\exitexample +\end{example} \pnum If an \grammarterm{unqualified-id}~(\ref{expr.prim}) is used in the @@ -1112,10 +1112,10 @@ transformed into a \grammarterm{qualified-id} expression in which the \grammarterm{nested-name-specifier} names the class scope from which the member is referenced. -\enternote +\begin{note} See~\ref{expr.prim} for restrictions on the use of non-static data members and non-static member functions. -\exitnote +\end{note} \pnum @@ -1124,24 +1124,24 @@ member, the \tcode{static} specifier shall only be used in the member declarations that appear within the \grammarterm{member-specification} of the class definition. -\enternote +\begin{note} It cannot be specified in member declarations that appear in namespace scope. -\exitnote +\end{note} \rSec2[class.static.mfct]{Static member functions} \indextext{member function!static}% \pnum -\enternote +\begin{note} The rules described in~\ref{class.mfct} apply to \tcode{static} member functions. -\exitnote +\end{note} \pnum -\enternote +\begin{note} A \tcode{static} member function does not have a \tcode{this} pointer~(\ref{class.this}). -\exitnote +\end{note} A \tcode{static} member function shall not be \tcode{virtual}. There shall not be a \tcode{static} and a non-static member function with the same name and the same parameter types~(\ref{over.load}). A @@ -1173,7 +1173,7 @@ \tcode{static} data member is in the scope of its class~(\ref{basic.scope.class}). \indextext{example!static@\tcode{static} member}% -\enterexample +\begin{example} \begin{codeblock} class process { @@ -1192,16 +1192,16 @@ \tcode{process}. In the \tcode{static} data member definition, the \grammarterm{initializer} expression refers to the \tcode{static} data member \tcode{running} of class \tcode{process}. -\exitexample +\end{example} -\enternote +\begin{note} Once the \tcode{static} data member has been defined, it exists even if no objects of its class have been created. -\enterexample +\begin{example} in the example above, \tcode{run_chain} and \tcode{running} exist even if no objects of class \tcode{process} are created by the program. -\exitexample -\exitnote +\end{example} +\end{note} \pnum If a non-volatile \tcode{const} \tcode{static} data member is @@ -1214,25 +1214,25 @@ \tcode{constexpr} specifier; if so, its declaration shall specify a \grammarterm{brace-or-equal-initializer} in which every \grammarterm{initializer-clause} that is an \grammarterm{assignment-expression} -is a constant expression. \enternote In both these cases, -the member may appear in constant expressions. \exitnote The +is a constant expression. \begin{note} In both these cases, +the member may appear in constant expressions. \end{note} The member shall still be defined in a namespace scope if it is odr-used~(\ref{basic.def.odr}) in the program and the namespace scope definition shall not contain an \grammarterm{initializer}. \pnum -\enternote +\begin{note} There shall be exactly one definition of a \tcode{static} data member that is odr-used~(\ref{basic.def.odr}) in a program; no diagnostic is required. -\exitnote +\end{note} Unnamed classes and classes contained directly or indirectly within unnamed classes shall not contain \tcode{static} data members. \pnum -\enternote +\begin{note} Static data members of a class in namespace scope have the linkage of that class~(\ref{basic.link}). A local class cannot have static data members~(\ref{class.local}). -\exitnote +\end{note} \pnum \tcode{Static} data members are initialized and destroyed exactly like @@ -1249,12 +1249,12 @@ \pnum In a union, at most one of the non-static data members can be active at any time, that is, the value of at most one of the non-static data members can be -stored in a union at any time. \enternote One special guarantee is made in order to +stored in a union at any time. \begin{note} One special guarantee is made in order to simplify the use of unions: If a standard-layout union contains several standard-layout structs that share a common initial sequence~(\ref{class.mem}), and if an object of this standard-layout union type contains one of the standard-layout structs, it is permitted to inspect the common initial sequence of any of standard-layout struct members; -see~\ref{class.mem}. \exitnote The size of a union is sufficient to contain the largest +see~\ref{class.mem}. \end{note} The size of a union is sufficient to contain the largest of its non-static data members. Each non-static data member is allocated as if it were the sole member of a struct. All non-static data members of a union object have the same address. @@ -1270,7 +1270,7 @@ \indextext{restriction!\idxcode{union}}% If a union contains a non-static data member of reference type the program is ill-formed. -\enternote If any non-static data member of a union has a non-trivial +\begin{note} If any non-static data member of a union has a non-trivial default constructor~(\ref{class.ctor}), copy constructor~(\ref{class.copy}), move constructor~(\ref{class.copy}), @@ -1278,10 +1278,10 @@ move assignment operator~(\ref{class.copy}), or destructor~(\ref{class.dtor}), the corresponding member function of the union must be user-provided or it will -be implicitly deleted~(\ref{dcl.fct.def.delete}) for the union. \exitnote +be implicitly deleted~(\ref{dcl.fct.def.delete}) for the union. \end{note} \pnum -\enterexample Consider the following union: +\begin{example} Consider the following union: \begin{codeblock} union U { @@ -1296,12 +1296,12 @@ copy/move constructor, copy/move assignment operator, and destructor. To use \tcode{U}, some or all of these member functions -must be user-provided.\exitexample +must be user-provided.\end{example} \pnum -\enternote In general, one must use explicit destructor calls and placement -new operators to change the active member of a union. \exitnote -\enterexample +\begin{note} In general, one must use explicit destructor calls and placement +new operators to change the active member of a union. \end{note} +\begin{example} Consider an object \tcode{u} of a \tcode{union} type \tcode{U} having non-static data members \tcode{m} of type \tcode{M} and \tcode{n} of type \tcode{N}. If \tcode{M} has a non-trivial destructor and \tcode{N} has a non-trivial constructor (for instance, if they declare or inherit @@ -1312,7 +1312,7 @@ u.m.~M(); new (&u.n) N; \end{codeblock} -\exitexample +\end{example} \rSec2[class.union.anon]{Anonymous unions} \indextext{\idxcode{union}!anonymous}% @@ -1328,17 +1328,17 @@ type. Each \grammarterm{member-declaration} in the \grammarterm{member-specification} of an anonymous union shall either define a non-static data member or be a \grammarterm{static_assert-declaration}. -\enternote +\begin{note} Nested types, anonymous unions, and functions cannot be declared within an anonymous union. -\exitnote +\end{note} The names of the members of an anonymous union shall be distinct from the names of any other entity in the scope in which the anonymous union is declared. For the purpose of name lookup, after the anonymous union definition, the members of the anonymous union are considered to have been defined in the scope in which the anonymous union is declared. \indextext{initialization!\idxcode{union}}% -\enterexample +\begin{example} \begin{codeblock} void f() { @@ -1350,7 +1350,7 @@ Here \tcode{a} and \tcode{p} are used like ordinary (nonmember) variables, but since they are union members they have the same address. -\exitexample +\end{example} \pnum \indextext{\idxcode{union}!global anonymous}% @@ -1368,7 +1368,7 @@ \pnum A union for which objects, pointers, or references are declared is not an anonymous union. -\enterexample +\begin{example} \begin{codeblock} void f() { @@ -1381,11 +1381,11 @@ The assignment to plain \tcode{aa} is ill-formed since the member name is not visible outside the union, and even if it were visible, it is not associated with any particular object. -\exitexample -\enternote +\end{example} +\begin{note} Initialization of unions with no user-declared constructors is described in~(\ref{dcl.init.aggr}). -\exitnote +\end{note} \pnum \indextext{class!union-like}% @@ -1396,7 +1396,7 @@ union is a variant member of \tcode{X}. In addition, a non-static data member of an anonymous union that is a member of \tcode{X} is also a variant member of \tcode{X}. At most one variant member of a union may have a default member initializer. -\enterexample +\begin{example} \begin{codeblock} union U { @@ -1411,7 +1411,7 @@ }; \end{codeblock} -\exitexample +\end{example} \rSec1[class.bit]{Bit-fields}% \indextext{bit-field} @@ -1442,21 +1442,21 @@ Alignment of bit-fields is \impldef{alignment of bit-fields within a class object}. \indextext{layout!bit-field}% Bit-fields are packed into some addressable allocation unit. -\enternote +\begin{note} Bit-fields straddle allocation units on some machines and not on others. Bit-fields are assigned right-to-left on some machines, left-to-right on others. -\exitnote +\end{note} \pnum \indextext{bit-field!unnamed}% A declaration for a bit-field that omits the \grammarterm{identifier} declares an \grammarterm{unnamed} bit-field. Unnamed bit-fields are not members and cannot be initialized. -\enternote +\begin{note} An unnamed bit-field is useful for padding to conform to externally-imposed layouts. -\exitnote +\end{note} \indextext{bit-field!zero~width~of}% \indextext{bit-field!alignment~of}% As a special case, an unnamed bit-field with a width of zero specifies @@ -1479,12 +1479,12 @@ \indextext{restriction!pointer~to bit-field}% A non-const reference shall not be bound to a bit-field~(\ref{dcl.init.ref}). -\enternote +\begin{note} If the initializer for a reference of type \tcode{const} \tcode{T\&} is an lvalue that refers to a bit-field, the reference is bound to a temporary initialized to hold the value of the bit-field; the reference is not bound to the bit-field directly. See~\ref{dcl.init.ref}. -\exitnote +\end{note} \pnum If the value \tcode{true} or \tcode{false} is stored into a bit-field of @@ -1495,7 +1495,7 @@ enough to hold all the values of that enumeration type~(\ref{dcl.enum}), the original enumerator value and the value of the bit-field shall compare equal. -\enterexample +\begin{example} \begin{codeblock} enum BOOL { FALSE=0, TRUE=1 }; @@ -1509,7 +1509,7 @@ { /* ... */ } } \end{codeblock} -\exitexample +\end{example} \rSec1[class.nest]{Nested class declarations}% \indextext{definition!nested~class}% @@ -1522,13 +1522,13 @@ is local to its enclosing class. \indextext{nested~class!scope~of}% The nested class is in the scope of its enclosing class. -\enternote +\begin{note} See~\ref{expr.prim} for restrictions on the use of non-static data members and non-static member functions. -\exitnote +\end{note} \indextext{example!nested~class}% -\enterexample +\begin{example} \begin{codeblock} int x; @@ -1554,13 +1554,13 @@ inner* p = 0; // error: \tcode{inner} not in scope \end{codeblock} -\exitexample +\end{example} \pnum Member functions and static data members of a nested class can be defined in a namespace scope enclosing the definition of their class. \indextext{example!nested~class definition}% -\enterexample +\begin{example} \begin{codeblock} struct enclose { @@ -1574,7 +1574,7 @@ void enclose::inner::f(int i) { /* ... */ } \end{codeblock} -\exitexample +\end{example} \pnum If class \tcode{X} is defined in a namespace scope, a nested class @@ -1582,7 +1582,7 @@ definition of class \tcode{X} or be later defined in a namespace scope enclosing the definition of class \tcode{X}. \indextext{example!nested~class forward~declaration}% -\enterexample +\begin{example} \begin{codeblock} class E { @@ -1592,7 +1592,7 @@ }; class E::I2 { }; // definition of nested class \end{codeblock} -\exitexample +\end{example} \pnum \indextext{friend~function!nested~class}% @@ -1617,7 +1617,7 @@ shall not odr-use~(\ref{basic.def.odr}) a variable with automatic storage duration from an enclosing scope. -\enterexample +\begin{example} \indextext{example!local~class}% \begin{codeblock} int x; @@ -1639,7 +1639,7 @@ local* p = 0; // error: \tcode{local} not in scope \end{codeblock} -\exitexample +\end{example} \pnum An enclosing function has no special access to members of the local @@ -1670,7 +1670,7 @@ Type names obey exactly the same scope rules as other names. In particular, type names defined within a class definition cannot be used outside their class without qualification. -\enterexample +\begin{example} \indextext{example!nested type~name}% \begin{codeblock} @@ -1685,5 +1685,5 @@ X::Y d; // OK X::I e; // OK \end{codeblock} -\exitexample% +\end{example}% \indextext{class|)} diff --git a/source/compatibility.tex b/source/compatibility.tex index 007acc6799..e8c03eb06a 100644 --- a/source/compatibility.tex +++ b/source/compatibility.tex @@ -784,8 +784,8 @@ Semantic transformation. If volatile semantics are required for the copy, a user-declared constructor or assignment must -be provided. \enternote This user-declared -constructor may be explicitly defaulted. \exitnote +be provided. \begin{note} This user-declared +constructor may be explicitly defaulted. \end{note} If non-volatile semantics are required, an explicit \tcode{const_cast} diff --git a/source/containers.tex b/source/containers.tex index 304fa1f312..73a913c3a1 100644 --- a/source/containers.tex +++ b/source/containers.tex @@ -44,14 +44,14 @@ \pnum All of the complexity requirements in this Clause are stated solely in terms of the number of operations on the contained objects. -\enterexample +\begin{example} The copy constructor of type \tcode{vector>} has linear complexity, even though the complexity of copying each contained \tcode{vector} is itself linear. -\exitexample +\end{example} \pnum For the components affected by this subclause that declare an \tcode{allocator_type}, @@ -63,10 +63,10 @@ where \tcode{U} is either \tcode{allocator_type::value_type} or an internal type used by the container. These functions are called only for the -container's element type, not for internal types used by the container. \enternote This +container's element type, not for internal types used by the container. \begin{note} This means, for example, that a node-based container might need to construct nodes containing aligned buffers and call \tcode{construct} to place the element into the buffer. -\exitnote +\end{note} \pnum In Tables~\ref{tab:containers.container.requirements}, @@ -317,9 +317,9 @@ exception. All other constructors for these container types take a \tcode{const allocator_type\&} argument. -\enternote If an invocation of a constructor uses the default value of an optional +\begin{note} If an invocation of a constructor uses the default value of an optional allocator argument, then the \tcode{Allocator} type must support value initialization. -\exitnote +\end{note} A copy of this allocator is used for any memory allocation and element construction performed, by these constructors and by all member functions, during the lifetime of each container object @@ -441,7 +441,7 @@ \tcode{swap()} function invalidates any references, pointers, or iterators referring to the elements -of the containers being swapped. \enternote The \tcode{end()} iterator does not refer to any element, so it may be invalidated. \exitnote +of the containers being swapped. \begin{note} The \tcode{end()} iterator does not refer to any element, so it may be invalidated. \end{note} \end{itemize} \pnum @@ -553,7 +553,7 @@ \end{codeblock} and its evaluation causes the following postcondition to hold: The value of \tcode{*p} is equivalent to the value of \tcode{rv} before the evaluation. -\enternote \tcode{rv} remains a valid object. Its state is unspecified \exitnote +\begin{note} \tcode{rv} remains a valid object. Its state is unspecified \end{note} \item \tcode{T} is \defnx{\tcode{CopyInsertable} into \tcode{X}} @@ -586,14 +586,14 @@ \end{codeblock} \end{itemize} -\enternote +\begin{note} A container calls \tcode{allocator_traits::construct(m, p, args)} to construct an element at \tcode{p} using \tcode{args}, with \tcode{m == get_allocator()}. The default \tcode{construct} in \tcode{std::allocator} will call \tcode{::new((void*)p) T(args)}, but specialized allocators may choose a different definition. -\exitnote +\end{note} \pnum In Table~\ref{tab:containers.allocatoraware}, \tcode{X} denotes an allocator-aware container class @@ -717,13 +717,13 @@ container, excepting \tcode{vector}, are modified concurrently. \pnum -\enternote For a \tcode{vector x} with a size greater than one, \tcode{x[1] = 5} +\begin{note} For a \tcode{vector x} with a size greater than one, \tcode{x[1] = 5} and \tcode{*x.begin() = 10} can be executed concurrently without a data race, but \tcode{x[0] = 5} and \tcode{*x.begin() = 10} executed concurrently may result in a data race. As an exception to the general rule, for a \tcode{vector y}, \tcode{y[0] = true} may race with \tcode{y[1] = true}. -\exitnote +\end{note} \rSec2[sequence.reqmts]{Sequence containers} @@ -1250,17 +1250,17 @@ and \tcode{const_iterator} are the same type. -\enternote \tcode{iterator} and \tcode{const_iterator} have identical semantics in this case, and \tcode{iterator} is convertible to \tcode{const_iterator}. Users can avoid violating the one-definition rule by always using \tcode{const_iterator} in their function parameter lists. \exitnote +\begin{note} \tcode{iterator} and \tcode{const_iterator} have identical semantics in this case, and \tcode{iterator} is convertible to \tcode{const_iterator}. Users can avoid violating the one-definition rule by always using \tcode{const_iterator} in their function parameter lists. \end{note} \pnum The associative containers meet all the requirements of Allocator-aware containers~(\ref{container.requirements.general}), except that for \tcode{map} and \tcode{multimap}, the requirements placed on \tcode{value_type} in Table~\ref{tab:containers.container.requirements} apply instead to \tcode{key_type} -and \tcode{mapped_type}. \enternote For example, in some cases \tcode{key_type} and \tcode{mapped_type} +and \tcode{mapped_type}. \begin{note} For example, in some cases \tcode{key_type} and \tcode{mapped_type} are required to be \tcode{CopyAssignable} even though the associated \tcode{value_type}, \tcode{pair}, is not -\tcode{CopyAssignable}. \exitnote +\tcode{CopyAssignable}. \end{note} \pnum In Table~\ref{tab:containers.associative.requirements}, @@ -1714,9 +1714,9 @@ \tcode{true} when passed those values. If \tcode{k1} and \tcode{k2} are equivalent, the container's hash function shall return the same value for both. -\enternote Thus, when an unordered associative container is instantiated with +\begin{note} Thus, when an unordered associative container is instantiated with a non-default \tcode{Pred} parameter it usually needs a non-default \tcode{Hash} -parameter as well. \exitnote +parameter as well. \end{note} For any two keys \tcode{k1} and \tcode{k2} in the same container, calling \tcode{pred(k1, k2)} shall always return the same value. For any key \tcode{k} in a container, calling \tcode{hash(k)} @@ -1749,11 +1749,11 @@ type, both \tcode{iterator} and \tcode{const_iterator} are constant iterators. It is unspecified whether or not \tcode{iterator} and \tcode{const_iterator} are the same type. -\enternote \tcode{iterator} and \tcode{const_iterator} have identical +\begin{note} \tcode{iterator} and \tcode{const_iterator} have identical semantics in this case, and \tcode{iterator} is convertible to \tcode{const_iterator}. Users can avoid violating the one-definition rule by always using \tcode{const_iterator} in their function parameter lists. -\exitnote +\end{note} \pnum \indextext{buckets}% @@ -1774,10 +1774,10 @@ containers~(\ref{container.requirements.general}), except that for \tcode{unordered_map} and \tcode{unordered_multimap}, the requirements placed on \tcode{value_type} in Table~\ref{tab:containers.container.requirements} apply instead to \tcode{key_type} -and \tcode{mapped_type}. \enternote For example, \tcode{key_type} and \tcode{mapped_type} +and \tcode{mapped_type}. \begin{note} For example, \tcode{key_type} and \tcode{mapped_type} are sometimes required to be \tcode{CopyAssignable} even though the associated \tcode{value_type}, \tcode{pair}, is not -\tcode{CopyAssignable}. \exitnote +\tcode{CopyAssignable}. \end{note} \pnum \indextext{unordered associative containers}% @@ -2696,9 +2696,9 @@ \end{codeblock} \pnum -\enternote The member variable \tcode{elems} is shown for exposition only, +\begin{note} The member variable \tcode{elems} is shown for exposition only, to emphasize that \tcode{array} is a class aggregate. The name \tcode{elems} -is not part of \tcode{array}'s interface. \exitnote +is not part of \tcode{array}'s interface. \end{note} \rSec3[array.cons]{\tcode{array} constructors, copy, and assignment} @@ -3133,7 +3133,7 @@ \pnum \remarks \tcode{shrink_to_fit} is a non-binding request to reduce memory use -but does not change the size of the sequence. \enternote The request is non-binding to allow latitude for implementation-specific optimizations. \exitnote +but does not change the size of the sequence. \begin{note} The request is non-binding to allow latitude for implementation-specific optimizations. \end{note} \end{itemdescr} \rSec3[deque.modifiers]{\tcode{deque} modifiers} @@ -3208,7 +3208,7 @@ and references to the erased elements. An erase operation that erases neither the first element nor the last element of a deque invalidates the past-the-end iterator and all iterators and references to all the elements of the deque. -\enternote \tcode{pop_front} and \tcode{pop_back} are erase operations. \exitnote +\begin{note} \tcode{pop_front} and \tcode{pop_back} are erase operations. \end{note} \pnum \complexity @@ -3249,9 +3249,9 @@ A \tcode{forward_list} is a container that supports forward iterators and allows constant time insert and erase operations anywhere within the sequence, with storage management handled automatically. Fast random access to list elements is not supported. -\enternote It is intended that \tcode{forward_list} have zero space or time overhead +\begin{note} It is intended that \tcode{forward_list} have zero space or time overhead relative to a hand-written C-style singly linked list. Features that would conflict with -that goal have been omitted.\exitnote +that goal have been omitted.\end{note} \pnum A \tcode{forward_list} satisfies all of the requirements of a container @@ -3267,10 +3267,10 @@ is additional semantic information. \pnum -\enternote Modifying any list requires access to the element preceding the first element +\begin{note} Modifying any list requires access to the element preceding the first element of interest, but in a \tcode{forward_list} there is no constant-time way to access a preceding element. For this reason, ranges that are modified, such as those supplied to -\tcode{erase} and \tcode{splice}, must be open at the beginning. \exitnote +\tcode{erase} and \tcode{splice}, must be open at the beginning. \end{note} \begin{codeblock} namespace std { @@ -5000,7 +5000,7 @@ \complexity Linear in the size of the sequence. \pnum -\remarks \tcode{shrink_to_fit} is a non-binding request to reduce \tcode{capacity()} to \tcode{size()}. \enternote The request is non-binding to allow latitude for implementation-specific optimizations. \exitnote +\remarks \tcode{shrink_to_fit} is a non-binding request to reduce \tcode{capacity()} to \tcode{size()}. \begin{note} The request is non-binding to allow latitude for implementation-specific optimizations. \end{note} If an exception is thrown other than by the move constructor of a non-\tcode{CopyInsertable} \tcode{T} there are no effects. \end{itemdescr} diff --git a/source/conversions.tex b/source/conversions.tex index 8a03705e5e..fb933f8dfd 100644 --- a/source/conversions.tex +++ b/source/conversions.tex @@ -29,13 +29,13 @@ \item Zero or one qualification conversion. \end{itemize} -\enternote +\begin{note} A standard conversion sequence can be empty, i.e., it can consist of no -conversions. \exitnote A standard conversion sequence will be applied to +conversions. \end{note} A standard conversion sequence will be applied to an expression if necessary to convert it to a required destination type. \pnum -\enternote +\begin{note} expressions with a given type will be implicitly converted to other types in several contexts: @@ -56,7 +56,7 @@ is (generally) the destination type. See~\ref{dcl.init},~\ref{dcl.init.ref}. \end{itemize} -\exitnote +\end{note} \pnum An expression \tcode{e} can be @@ -98,21 +98,21 @@ is used as a glvalue if and only if the initialization uses it as a glvalue. \pnum -\enternote +\begin{note} For class types, user-defined conversions are considered as well; see~\ref{class.conv}. In general, an implicit conversion sequence~(\ref{over.best.ics}) consists of a standard conversion sequence followed by a user-defined conversion followed by another standard conversion sequence. -\exitnote +\end{note} \pnum -\enternote +\begin{note} There are some contexts where certain conversions are suppressed. For example, the lvalue-to-rvalue conversion is not done on the operand of the unary \tcode{\&} operator. Specific exceptions are given in the descriptions of those operators and contexts. -\exitnote +\end{note} \rSec1[conv.lval]{Lvalue-to-rvalue conversion} @@ -143,7 +143,7 @@ \tcode{ex}~(\ref{basic.def.odr}), \end{itemize} the value contained in the referenced object is not accessed. -\enterexample +\begin{example} \begin{codeblock} struct S { int n; }; auto f() { @@ -155,7 +155,7 @@ int m = g(false); // undefined behavior due to access of \tcode{x.n} outside its lifetime int n = g(true); // OK, does not access \tcode{y.n} \end{codeblock} -\exitexample +\end{example} In all other cases, the result of the conversion is determined according to the following rules: @@ -163,11 +163,11 @@ \item If \tcode{T} is (possibly cv-qualified) \tcode{std::nullptr_t}, the result is a null pointer constant~(\ref{conv.ptr}). -\enternote +\begin{note} Since no value is fetched from memory, there is no side effect for a volatile access~(\ref{intro.execution}), and an inactive member of a union~(\ref{class.union}) may be accessed. -\exitnote +\end{note} \item Otherwise, if \tcode{T} has a class type, the conversion copy-initializes a temporary of type \tcode{T} from @@ -184,8 +184,8 @@ \end{itemize} \pnum -\enternote -See also~\ref{basic.lval}.\exitnote +\begin{note} +See also~\ref{basic.lval}.\end{note} \rSec1[conv.array]{Array-to-pointer conversion} @@ -207,10 +207,10 @@ lvalue that refers to a non-static member function cannot be obtained.} \pnum -\enternote +\begin{note} See~\ref{over.over} for additional rules for the case where the function is overloaded. -\exitnote +\end{note} \rSec1[conv.qual]{Qualification conversions} @@ -235,11 +235,11 @@ If $P_i$ designates an array, the cv-qualifiers $cv_{i+1}$ on the element type are also taken as the cv-qualifiers $cv_i$ of the array. -\enterexample +\begin{example} The type denoted by the \grammarterm{type-id} \tcode{const int **} has two cv-decompositions, taking \tcode{U} as ``\tcode{int}'' and as ``pointer to \tcode{const int}''. -\exitexample +\end{example} The \placeholder{n}-tuple of cv-qualifiers after the first one in the longest cv-decomposition of \tcode{T}, that is, $cv_1$, $cv_2$, $\cdots$, $cv_n$, is called the @@ -271,7 +271,7 @@ then \tcode{const} is in every $\mathit{cv}_k^2$ for $0 < k < i$. \end{itemize} -\enternote +\begin{note} if a program could assign a pointer of type \tcode{T**} to a pointer of type \tcode{const} \tcode{T**} (that is, if line \tcode{\#1} below were allowed), a program could inadvertently modify a \tcode{const} object @@ -286,10 +286,10 @@ *pc = 'C'; // \#2: modifies a \tcode{const} object } \end{codeblock} -\exitnote +\end{note} \pnum -\enternote +\begin{note} A prvalue of type ``pointer to \cvqual{cv1} \tcode{T}'' can be converted to a prvalue of type ``pointer to \cvqual{cv2} \tcode{T}'' if ``\cvqual{cv2} \tcode{T}'' is more cv-qualified than ``\cvqual{cv1} @@ -298,13 +298,13 @@ \tcode{T}'' can be converted to a prvalue of type ``pointer to member of \tcode{X} of type \cvqual{cv2} \tcode{T}'' if ``\cvqual{cv2} \tcode{T}'' is more cv-qualified than ``\cvqual{cv1} \tcode{T}''. -\exitnote +\end{note} \pnum -\enternote +\begin{note} Function types (including those used in pointer to member function types) are never cv-qualified~(\ref{dcl.fct}). -\exitnote +\end{note} \indextext{conversion!qualification|)} \rSec1[conv.prom]{Integral promotions} @@ -390,10 +390,10 @@ If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source integer (modulo $2^n$ where $n$ is the number of bits used to represent the unsigned type). -\enternote +\begin{note} In a two's complement representation, this conversion is conceptual and there is no change in the bit pattern (if there is no truncation). -\exitnote +\end{note} \pnum \indextext{conversion!to signed}% @@ -437,9 +437,9 @@ \indextext{value!undefined unrepresentable integral}% The behavior is undefined if the truncated value cannot be represented in the destination type. -\enternote +\begin{note} If the destination type is \tcode{bool}, see~\ref{conv.bool}. -\exitnote +\end{note} \pnum \indextext{conversion!integral~to~floating}% @@ -450,8 +450,8 @@ converted is in the range of values that can be represented but the value cannot be represented exactly, it is an \impldef{value of result of inexact integer to floating-point conversion} choice of either the next lower or higher representable -value. \enternote Loss of precision occurs if the integral value cannot be represented -exactly as a value of the floating type. \exitnote If the value being converted is +value. \begin{note} Loss of precision occurs if the integral value cannot be represented +exactly as a value of the floating type. \end{note} If the value being converted is outside the range of values that can be represented, the behavior is undefined. If the source type is \tcode{bool}, the value \tcode{false} is converted to zero and the value \tcode{true} is converted to one. @@ -478,7 +478,7 @@ pointer conversion followed by a qualification conversion~(\ref{conv.qual}). A null pointer constant of integral type can be converted to a prvalue of type \tcode{std::nullptr_t}. -\enternote The resulting prvalue is not a null pointer value. \exitnote +\begin{note} The resulting prvalue is not a null pointer value. \end{note} \pnum A prvalue of type ``pointer to \cvqual{cv} \tcode{T}'', where \tcode{T} @@ -561,7 +561,7 @@ can be converted to a prvalue of type ``pointer to member of type function''. The result points to the member function. -\enterexample +\begin{example} \begin{codeblock} void (*p)() throw(int); void (**pp)() noexcept = &p; // error: cannot convert to pointer to \tcode{noexcept} function @@ -569,7 +569,7 @@ struct S { typedef void (*p)(); operator p(); }; void (*q)() noexcept = S(); // error: cannot convert to pointer to \tcode{noexcept} function \end{codeblock} -\exitexample +\end{example} \rSec1[conv.bool]{Boolean conversions} @@ -630,9 +630,9 @@ \tcode{T3}. \end{itemize} -\enternote +\begin{note} The integer conversion rank is used in the definition of the integral promotions~(\ref{conv.prom}) and the usual arithmetic conversions (Clause~\ref{expr}). -\exitnote% +\end{note}% \indextext{conversion!standard|)} diff --git a/source/declarations.tex b/source/declarations.tex index fbd31f5351..693fac4c80 100644 --- a/source/declarations.tex +++ b/source/declarations.tex @@ -75,7 +75,7 @@ attribute-specifier-seq \terminal{;} \end{bnf} -\enternote +\begin{note} \grammarterm{asm-definition}{s} are described in~\ref{dcl.asm}, and \grammarterm{linkage-specification}{s} are described in~\ref{dcl.link}. \grammarterm{Function-definition}{s} are described in~\ref{dcl.fct.def} and @@ -83,7 +83,7 @@ \grammarterm{Namespace-definition}{s} are described in~\ref{namespace.def}, \grammarterm{using-declaration}{s} are described in~\ref{namespace.udecl} and \grammarterm{using-directive}{s} are described in~\ref{namespace.udir}. -\exitnote +\end{note} \pnum A @@ -104,14 +104,14 @@ appertains to each of the entities declared by the \grammarterm{declarator}{s} of the \grammarterm{init-declarator-list}. -\enternote In the declaration for an entity, attributes appertaining to that +\begin{note} In the declaration for an entity, attributes appertaining to that entity may appear at the start of the declaration and after the \grammarterm{declarator-id} for that declaration. -\exitnote \enterexample +\end{note} \begin{example} \begin{codeblock} [[noreturn]] void f [[noreturn]] (); // OK \end{codeblock} -\exitexample +\end{example} \pnum Except where otherwise specified, the meaning of an \grammarterm{attribute-declaration} @@ -148,13 +148,13 @@ the \grammarterm{decl-specifier-seq} shall introduce one or more names into the program, or shall redeclare a name introduced by a previous declaration. -\enterexample +\begin{example} \begin{codeblock} enum { }; // ill-formed typedef class { }; // ill-formed \end{codeblock} -\exitexample +\end{example} \pnum \indextext{\idxgram{static_assert}}% @@ -170,11 +170,11 @@ except that characters not in the basic source character set~(\ref{lex.charset}) are not required to appear in the diagnostic message. -\enterexample +\begin{example} \begin{codeblock} static_assert(char(-1) < 0, "this library requires plain 'char' to be signed"); -\end{codeblock}\exitexample +\end{codeblock}\end{example} \pnum An \grammarterm{empty-declaration} has no effect. @@ -217,12 +217,12 @@ A \grammarterm{nodeclspec-function-declaration} shall declare a constructor, destructor, or conversion function. \footnote{The ``implicit int'' rule of C is no longer supported.} -\enternote +\begin{note} A \grammarterm{nodeclspec-function-declaration} can only be used in a \grammarterm{template-declaration}~(Clause~\ref{temp}), \grammarterm{explicit-instantiation}~(\ref{temp.explicit}), or \grammarterm{explicit-specialization}~(\ref{temp.expl.spec}). -\exitnote +\end{note} \rSec1[dcl.spec]{Specifiers}% \indextext{specifier|(} @@ -266,7 +266,7 @@ \grammarterm{decl-specifier-seq}. The sequence shall be self-consistent as described below. -\enterexample +\begin{example} \begin{codeblock} typedef char* Pc; @@ -285,25 +285,25 @@ void f(const Pc); // \tcode{void f(char* const)} (not \tcode{const char*}) void g(const int Pc); // \tcode{void g(const int)} \end{codeblock} -\exitexample +\end{example} \pnum \indextext{\idxcode{signed}!typedef@\tcode{typedef}~and}% \indextext{\idxcode{unsigned}!typedef@\tcode{typedef}~and}% \indextext{\idxcode{long}!typedef@\tcode{typedef}~and}% \indextext{\idxcode{short}!typedef@\tcode{typedef}~and}% -\enternote +\begin{note} Since \tcode{signed}, \tcode{unsigned}, \tcode{long}, and \tcode{short} by default imply \tcode{int}, a \grammarterm{type-name} appearing after one of those specifiers is treated as the name being (re)declared. -\enterexample +\begin{example} \begin{codeblock} void h(unsigned Pc); // \tcode{void h(unsigned int)} void k(unsigned int Pc); // \tcode{void k(unsigned int)} \end{codeblock} -\exitexample -\exitnote +\end{example} +\end{note} \rSec2[dcl.stc]{Storage class specifiers}% \indextext{specifier!storage~class}% @@ -346,11 +346,11 @@ explicit instantiation~(\ref{temp.explicit}) directive. \pnum -\enternote +\begin{note} A variable declared without a \grammarterm{storage-class-specifier} at block scope or declared as a function parameter has automatic storage duration by default~(\ref{basic.stc.auto}). -\exitnote +\end{note} \pnum The \tcode{thread_local} specifier @@ -388,12 +388,12 @@ \indextext{consistency!linkage}% For the linkage of a name declared with an \tcode{extern} specifier, see~\ref{basic.link}. -\enternote +\begin{note} The \tcode{extern} keyword can also be used in \nonterminal{explicit-instantiation}s and \nonterminal{linkage-specification}s, but it is not a \nonterminal{storage-class-specifier} in such contexts. -\exitnote +\end{note} \pnum The linkages implied by successive declarations for a given entity shall @@ -401,7 +401,7 @@ same variable name or the same overloading of a function name shall imply the same linkage. Each function in a given set of overloaded functions can have a different linkage, however. -\enterexample +\begin{example} \indextext{example!linkage consistency}% \begin{codeblock} @@ -437,14 +437,14 @@ extern int d; // \tcode{d} has external linkage static int d; // error: inconsistent linkage \end{codeblock} -\exitexample +\end{example} \pnum \indextext{declaration!forward}% The name of a declared but undefined class can be used in an \tcode{extern} declaration. Such a declaration can only be used in ways that do not require a complete class type. -\enterexample +\begin{example} \begin{codeblock} struct S; @@ -457,13 +457,13 @@ f(); // error: \tcode{S} is incomplete } \end{codeblock} -\exitexample +\end{example} \pnum The \tcode{mutable} specifier shall appear only in the declaration of a non-static data member~(\ref{class.mem}) whose type is neither const-qualified nor a reference type. -\enterexample +\begin{example} \begin{codeblock} class X { @@ -471,7 +471,7 @@ mutable int* const q; // ill-formed }; \end{codeblock} -\exitexample +\end{example} \pnum The \tcode{mutable} specifier on a class data member nullifies a @@ -519,10 +519,10 @@ An inline function shall be defined in every translation unit in which it is odr-used and shall have exactly the same definition in every case~(\ref{basic.def.odr}). -\enternote +\begin{note} A call to the inline function may be encountered before its definition appears in the translation unit. -\exitnote +\end{note} If the definition of a function appears in a translation unit before its first declaration as inline, the program is ill-formed. If a function with external linkage is declared inline in one translation unit, it @@ -579,7 +579,7 @@ A \grammarterm{typedef-name} is thus a synonym for another type. A \grammarterm{typedef-name} does not introduce a new type the way a class declaration~(\ref{class.name}) or enum declaration does. -\enterexample +\begin{example} \indextext{example!\idxcode{typedef}}% after @@ -596,7 +596,7 @@ are all correct declarations; the type of \tcode{distance} is \tcode{int} and that of \tcode{metricp} is ``pointer to \tcode{int}''. -\exitexample +\end{example} \pnum A \grammarterm{typedef-name} can also be introduced by an @@ -607,7 +607,7 @@ Such a \grammarterm{typedef-name} has the same semantics as if it were introduced by the \tcode{typedef} specifier. In particular, it does not define a new type. -\enterexample +\begin{example} \begin{codeblock} using handler_t = void (*)(int); @@ -616,7 +616,7 @@ using cell = pair; // ill-formed \end{codeblock} -\exitexample +\end{example} The \grammarterm{defining-type-specifier-seq} of the \grammarterm{defining-type-id} shall not define a class or enumeration if the \grammarterm{alias-declaration} @@ -627,7 +627,7 @@ In a given non-class scope, a \tcode{typedef} specifier can be used to redefine the name of any type declared in that scope to refer to the type to which it already refers. -\enterexample +\begin{example} \begin{codeblock} typedef struct s { /* ... */ } s; @@ -635,14 +635,14 @@ typedef int I; typedef I I; \end{codeblock} -\exitexample +\end{example} \pnum In a given class scope, a \tcode{typedef} specifier can be used to redefine any \grammarterm{class-name} declared in that scope that is not also a \grammarterm{typedef-name} to refer to the type to which it already refers. -\enterexample +\begin{example} \begin{codeblock} struct S { @@ -651,14 +651,14 @@ typedef A A; // error }; \end{codeblock} -\exitexample +\end{example} \pnum If a \tcode{typedef} specifier is used to redefine in a given scope an entity that can be referenced using an \grammarterm{elaborated-type-specifier}, the entity can continue to be referenced by an \grammarterm{elaborated-type-specifier} or as an enumeration or class name -in an enumeration or class definition respectively. \enterexample +in an enumeration or class definition respectively. \begin{example} \begin{codeblock} struct S; typedef struct S S; @@ -667,35 +667,35 @@ } struct S { }; // OK \end{codeblock} -\exitexample +\end{example} \pnum In a given scope, a \tcode{typedef} specifier shall not be used to redefine the name of any type declared in that scope to refer to a different type. -\enterexample +\begin{example} \begin{codeblock} class complex { /* ... */ }; typedef int complex; // error: redefinition \end{codeblock} -\exitexample +\end{example} \pnum Similarly, in a given scope, a class or enumeration shall not be declared with the same name as a \grammarterm{typedef-name} that is declared in that scope and refers to a type other than the class or enumeration itself. -\enterexample +\begin{example} \begin{codeblock} typedef int complex; class complex @\tcode{\{ /* ... */ \}}@; // error: redefinition \end{codeblock} -\exitexample +\end{example} \pnum -\enternote +\begin{note} \indextext{class~name!\idxcode{typedef}}% A \grammarterm{typedef-name} that names a class type, or a cv-qualified version thereof, is also a \grammarterm{class-name}~(\ref{class.name}). If @@ -704,8 +704,8 @@ definition (Clause~\ref{class}), a constructor declaration~(\ref{class.ctor}), or a destructor declaration~(\ref{class.dtor}), the program is ill-formed. -\exitnote -\enterexample +\end{note} +\begin{example} \begin{codeblock} struct S { @@ -718,7 +718,7 @@ S a = T(); // OK struct T * p; // error \end{codeblock} -\exitexample +\end{example} \pnum \indextext{class~name!\idxcode{typedef}}% @@ -728,12 +728,12 @@ \grammarterm{typedef-name} declared by the declaration to be that class type (or enum type) is used to denote the class type (or enum type) for linkage purposes only~(\ref{basic.link}). -\enterexample +\begin{example} \begin{codeblock} typedef struct { } *ps, S; // \tcode{S} is the class name for linkage purposes \end{codeblock} -\exitexample +\end{example} \rSec2[dcl.friend]{The \tcode{friend} specifier}% \indextext{specifier!\idxcode{friend}} @@ -753,12 +753,12 @@ data member of a literal type~(\ref{basic.types}). If any declaration of a function or function template has a \tcode{constexpr} specifier, -then all its declarations shall contain the \tcode{constexpr} specifier. \enternote An +then all its declarations shall contain the \tcode{constexpr} specifier. \begin{note} An explicit specialization can differ from the template declaration with respect to the -\tcode{constexpr} specifier. \exitnote -\enternote -Function parameters cannot be declared \tcode{constexpr}.\exitnote -\enterexample +\tcode{constexpr} specifier. \end{note} +\begin{note} +Function parameters cannot be declared \tcode{constexpr}.\end{note} +\begin{example} \begin{codeblock} constexpr void square(int &x); // OK: declaration constexpr int bufsz = 1024; // OK: definition @@ -782,7 +782,7 @@ } extern constexpr int memsz; // error: not a definition \end{codeblock} -\exitexample +\end{example} \pnum A \tcode{constexpr} specifier used in the declaration of a function that is not a @@ -833,7 +833,7 @@ \end{itemize} -\enterexample +\begin{example} \begin{codeblock} constexpr int square(int x) { return x * x; } // OK @@ -860,7 +860,7 @@ return r; } \end{codeblock} -\exitexample +\end{example} \pnum \indextext{specifier!\idxcode{constexpr}!constructor}% @@ -912,7 +912,7 @@ constructor. \end{itemize} -\enterexample +\begin{example} \begin{codeblock} struct Length { constexpr explicit Length(int i = 0) : val(i) { } @@ -920,7 +920,7 @@ int val; }; \end{codeblock} -\exitexample +\end{example} \pnum For a \tcode{constexpr} function or \tcode{constexpr} constructor @@ -930,7 +930,7 @@ constant expression~(\ref{expr.const}), or, for a constructor, a constant initializer for some object~(\ref{basic.start.static}), the program is ill-formed; no diagnostic required. -\enterexample +\begin{example} \begin{codeblock} constexpr int f(bool b) { return b ? throw 0 : 0; } // OK @@ -949,7 +949,7 @@ }; \end{codeblock} -\exitexample +\end{example} \pnum If the instantiated template specialization of a \tcode{constexpr} function @@ -972,7 +972,7 @@ \pnum The \tcode{constexpr} specifier has no -effect on the type of a \tcode{constexpr} function or a \tcode{constexpr} constructor. \enterexample +effect on the type of a \tcode{constexpr} function or a \tcode{constexpr} constructor. \begin{example} \begin{codeblock} constexpr int bar(int x, int y) // OK { return x + y + x*y; } @@ -980,7 +980,7 @@ int bar(int x, int y) // error: redefinition of \tcode{bar} { return x * 2 + 3 * y; } \end{codeblock} -\exitexample +\end{example} \pnum A \tcode{constexpr} specifier used in an object @@ -992,10 +992,10 @@ that call shall be a constant expression~(\ref{expr.const}). Otherwise, or if a \tcode{constexpr} specifier is used in a reference declaration, -every full-expression that appears in its initializer shall be a constant expression. \enternote Each +every full-expression that appears in its initializer shall be a constant expression. \begin{note} Each implicit conversion used in converting the initializer expressions and each constructor call -used for the initialization is part of such a full-expression. \exitnote -\enterexample +used for the initialization is part of such a full-expression. \end{note} +\begin{example} \begin{codeblock} struct pixel { int x, y; @@ -1003,7 +1003,7 @@ constexpr pixel ur = { 1294, 1024 };// OK constexpr pixel origin; // error: initializer missing \end{codeblock} -\exitexample +\end{example} \rSec2[dcl.type]{Type specifiers}% \indextext{specifier!type|see{type~specifier}} @@ -1083,7 +1083,7 @@ The ``implicit int'' rule of C is no longer supported.} \pnum -\enternote +\begin{note} \grammarterm{enum-specifier}{s}, \grammarterm{class-specifier}{s}, and @@ -1095,7 +1095,7 @@ and \ref{temp.res}, respectively. The remaining \grammarterm{type-specifier}{s} are discussed in the rest of this section. -\exitnote +\end{note} \rSec3[dcl.type.cv]{The \grammarterm{cv-qualifiers}}% \indextext{specifier!cv-qualifier}% @@ -1110,21 +1110,21 @@ \grammarterm{decl-specifier-seq}, the \grammarterm{init-declarator-list} or \grammarterm{member-declarator-list} of the declaration shall not be empty. -\enternote +\begin{note} \ref{basic.type.qualifier} and \ref{dcl.fct} describe how cv-qualifiers affect object and function types. -\exitnote -Redundant cv-qualifications are ignored. \enternote For example, -these could be introduced by typedefs.\exitnote +\end{note} +Redundant cv-qualifications are ignored. \begin{note} For example, +these could be introduced by typedefs.\end{note} \pnum -\enternote +\begin{note} Declaring a variable \tcode{const} can affect its linkage~(\ref{dcl.stc}) and its usability in constant expressions~(\ref{expr.const}). As described in~\ref{dcl.init}, the definition of an object or subobject of const-qualified type must specify an initializer or be subject to default-initialization. -\exitnote +\end{note} \pnum A pointer or reference to a cv-qualified type need not actually point or @@ -1132,17 +1132,17 @@ const-qualified access path cannot be used to modify an object even if the object referenced is a non-const object and can be modified through some other access path. -\enternote +\begin{note} Cv-qualifiers are supported by the type system so that they cannot be subverted without casting~(\ref{expr.const.cast}). -\exitnote +\end{note} \pnum \indextext{const~object@\tcode{const}-object!undefined change~to}% Except that any class member declared \tcode{mutable}~(\ref{dcl.stc}) can be modified, any attempt to modify a \tcode{const} object during its lifetime~(\ref{basic.life}) results in undefined behavior. -\enterexample +\begin{example} \begin{codeblock} const int ci = 3; // cv-qualified (initialized as required) @@ -1182,7 +1182,7 @@ p->x.i = 99; // well-formed: \tcode{mutable} member can be modified p->x.j = 99; // undefined: modifies a \tcode{const} member \end{codeblock} -\exitexample +\end{example} \pnum What constitutes an access to an object that has volatile-qualified type is @@ -1194,7 +1194,7 @@ \pnum \indextext{type~specifier!\idxcode{volatile}}% \indextext{\idxcode{volatile}!implementation-defined}% -\enternote +\begin{note} \tcode{volatile} is a hint to the implementation to avoid aggressive optimization involving the object because the value of the object might be changed by means undetectable by an implementation. @@ -1203,7 +1203,7 @@ See~\ref{intro.execution} for detailed semantics. In general, the semantics of \tcode{volatile} are intended to be the same in \Cpp as they are in C. -\exitnote +\end{note} \rSec3[dcl.type.simple]{Simple type specifiers}% \indextext{type specifier!simple} @@ -1325,11 +1325,11 @@ \pnum When multiple \grammarterm{simple-type-specifiers} are allowed, they can be freely intermixed with other \grammarterm{decl-specifiers} in any order. -\enternote +\begin{note} It is implementation-defined whether objects of \tcode{char} type are represented as signed or unsigned quantities. The \tcode{signed} specifier forces \tcode{char} objects to be signed; it is redundant in other contexts. -\exitnote +\end{note} \clearpage \pnum @@ -1357,7 +1357,7 @@ The operand of the \tcode{decltype} specifier is an unevaluated operand (Clause~\ref{expr}). -\enterexample +\begin{example} \begin{codeblock} const int&& foo(); int i; @@ -1368,14 +1368,14 @@ decltype(a->x) x3; // type is \tcode{double} decltype((a->x)) x4 = x3; // type is \tcode{const double\&} \end{codeblock} -\exitexample -\enternote +\end{example} +\begin{note} The rules for determining types involving \tcode{decltype(auto)} are specified in~\ref{dcl.spec.auto}. -\exitnote +\end{note} \pnum -\enternote in the case where the operand of a \grammarterm{decltype-specifier} +\begin{note} in the case where the operand of a \grammarterm{decltype-specifier} is a function call and the return type of the function is a class type, a special rule~(\ref{expr.call}) ensures that the return type is not required to be complete (as it would be if the call appeared in a sub-expression or outside @@ -1384,7 +1384,7 @@ \grammarterm{decltype-specifier} is analogous to a use of a \grammarterm{typedef-name}, so the usual reasons for requiring a complete type do not apply. In particular, it is not necessary to allocate storage for a temporary object or to enforce the -semantic constraints associated with invoking the type's destructor. \enterexample +semantic constraints associated with invoking the type's destructor. \begin{example} \begin{codeblock} template struct A { ~A() = delete; }; template auto h() @@ -1413,7 +1413,7 @@ // destructor is used, so the program is ill-formed. } \end{codeblock} -\exitexample\exitnote +\end{example}\end{note} \rSec3[dcl.type.elab]{Elaborated type specifiers}% \indextext{type specifier!elaborated}% @@ -1464,7 +1464,7 @@ an alias template specialization, the \grammarterm{elaborated-type-specifier} is ill-formed. -\enternote +\begin{note} This implies that, within a class template with a template \grammarterm{type-parameter} \tcode{T}, the declaration @@ -1473,7 +1473,7 @@ \end{codeblock} is ill-formed. However, the similar declaration \tcode{friend T;} is allowed~(\ref{class.friend}). -\exitnote +\end{note} \pnum The \grammarterm{class-key} or \tcode{enum} keyword @@ -1491,13 +1491,13 @@ (Clause~\ref{class}), and either the \tcode{class} or \tcode{struct} \grammarterm{class-key} shall be used to refer to a class (Clause~\ref{class}) declared using the \tcode{class} or \tcode{struct} -\grammarterm{class-key}. \enterexample +\grammarterm{class-key}. \begin{example} \begin{codeblock} enum class E { a, b }; enum E x = E::a; // OK \end{codeblock} -\exitexample +\end{example} \rSec3[dcl.spec.auto]{\tcode{auto} specifier}% \indextext{type specifier!\idxcode{auto}} @@ -1528,11 +1528,11 @@ \grammarterm{decl-specifier}{s} in the \grammarterm{decl-specifier-seq} of a \grammarterm{parameter-declaration} of a \grammarterm{lambda-expression}, the \indextext{generic lambda!definition of}% -lambda is a \term{generic lambda}~(\ref{expr.prim.lambda}). \enterexample +lambda is a \term{generic lambda}~(\ref{expr.prim.lambda}). \begin{example} \begin{codeblock} auto glambda = [](int i, auto a) { return i; }; // OK: a generic lambda \end{codeblock} -\exitexample +\end{example} \pnum The type of a variable declared using \tcode{auto} or \tcode{decltype(auto)} is @@ -1555,7 +1555,7 @@ the \grammarterm{expression-list} shall be a single \grammarterm{assignment-expression}. -\enterexample +\begin{example} \begin{codeblock} auto x = 5; // OK: \tcode{x} has type \tcode{int} const auto *v = &x, u = 6; // OK: \tcode{v} has type \tcode{const int*}, \tcode{u} has type \tcode{const int} @@ -1565,7 +1565,7 @@ auto g() { return 0.0; } // OK: \tcode{g} returns \tcode{double} auto h(); // OK: \tcode{h}'s return type will be deduced when it is defined \end{codeblock} -\exitexample +\end{example} \pnum A placeholder type can also be used in declaring a variable in @@ -1615,7 +1615,7 @@ If the deduction fails, the declaration is ill-formed. Otherwise, the type deduced for the variable or return type is obtained by substituting the deduced \tcode{U} into \tcode{P}. -\enterexample +\begin{example} \begin{codeblock} auto x1 = { 1, 2 }; // \tcode{decltype(x1)} is \tcode{std::initializer_list} auto x2 = { 1, 2.0 }; // error: cannot deduce element type @@ -1623,9 +1623,9 @@ auto x4 = { 3 }; // \tcode{decltype(x4)} is \tcode{std::initializer_list} auto x5{ 3 }; // \tcode{decltype(x5)} is \tcode{int} \end{codeblock} -\exitexample +\end{example} -\enterexample +\begin{example} \begin{codeblock} const auto &i = expr; \end{codeblock} @@ -1636,7 +1636,7 @@ \begin{codeblock} template void f(const U& u); \end{codeblock} -\exitexample +\end{example} If the placeholder is the \tcode{decltype(auto)} \grammarterm{type-specifier}, the declared type of the variable or return type of the function shall be the @@ -1645,7 +1645,7 @@ \grammarterm{initializer-clause} or \grammarterm{expression-list} of the \grammarterm{initializer} or the \grammarterm{expression} of the \tcode{return} statement had -been the operand of the \tcode{decltype}. \enterexample +been the operand of the \tcode{decltype}. \begin{example} \begin{codeblock} int i; int&& f(); @@ -1662,7 +1662,7 @@ auto *x7a = &i; // \tcode{decltype(x7a)} is \tcode{int*} decltype(auto)*x7d = &i; // error, declared type is not plain \tcode{decltype(auto)} \end{codeblock} -\exitexample +\end{example} \pnum If the \grammarterm{init-declarator-list} contains more than one @@ -1671,12 +1671,12 @@ described above, and if the type that replaces the placeholder type is not the same in each deduction, the program is ill-formed. -\enterexample +\begin{example} \begin{codeblock} auto x = 5, *y = &x; // OK: \tcode{auto} is \tcode{int} auto a = 5, b = { 1, 2 }; // error: different types for \tcode{auto} \end{codeblock} -\exitexample% +\end{example}% \indextext{specifier|)} \pnum @@ -1690,12 +1690,12 @@ \tcode{return} statements, the return type is deduced as though from a \tcode{return} statement with no operand at the closing brace of the function body. -\enterexample +\begin{example} \begin{codeblock} auto f() { } // OK, return type is \tcode{void} auto* g() { } // error, cannot deduce \tcode{auto*} from \tcode{void()} \end{codeblock} -\exitexample +\end{example} \pnum If the type of an entity with an undeduced placeholder type is needed to @@ -1703,7 +1703,7 @@ \tcode{return} statement has been seen in a function, however, the return type deduced from that statement can be used in the rest of the function, including in other \tcode{return} statements. -\enterexample +\begin{example} \begin{codeblock} auto n = n; // error, \tcode{n}'s type is unknown auto f(); @@ -1715,17 +1715,17 @@ return sum(i-1)+i; // OK, \tcode{sum}'s return type has been deduced } \end{codeblock} -\exitexample +\end{example} \pnum Return type deduction for a function template with a placeholder in its declared type occurs when the definition is instantiated even if the function body contains a \tcode{return} statement with a non-type-dependent operand. -\enternote Therefore, any use of a specialization of the function template will +\begin{note} Therefore, any use of a specialization of the function template will cause an implicit instantiation. Any errors that arise from this instantiation are not in the immediate context of the function type and can result in the -program being ill-formed. \exitnote -\enterexample +program being ill-formed. \end{note} +\begin{example} \begin{codeblock} template auto f(T t) { return t; } // return type deduced at instantiation time typedef decltype(f(1)) fint_t; // instantiates \tcode{f} to deduce return type @@ -1733,13 +1733,13 @@ void g() { int (*p)(int*) = &f; } // instantiates both \tcode{f}s to determine return types, // chooses second \end{codeblock} -\exitexample +\end{example} \pnum Redeclarations or specializations of a function or function template with a declared return type that uses a placeholder type shall also use that placeholder, not a deduced type. -\enterexample +\begin{example} \begin{codeblock} auto f(); auto f() { return 42; } // return type is \tcode{int} @@ -1763,7 +1763,7 @@ }; auto frf(int i) { return i; } // not a friend of \tcode{A} \end{codeblock} -\exitexample +\end{example} \pnum A function declared with a return type that uses a placeholder type shall not @@ -1774,14 +1774,14 @@ instantiation of an entity declared using a placeholder type, but it also does not prevent that entity from being instantiated as needed to determine its type. -\enterexample +\begin{example} \begin{codeblock} template auto f(T t) { return t; } extern template auto f(int); // does not instantiate \tcode{f} int (*p)(int) = f; // instantiates \tcode{f} to determine its return type, but an explicit // instantiation definition is still required somewhere in the program \end{codeblock} -\exitexample +\end{example} \rSec1[dcl.enum]{Enumeration declarations}% \indextext{enumeration}% @@ -1852,9 +1852,9 @@ ``\tcode{enum} \grammarterm{nested-name-specifier\opt} \grammarterm{identifier}'' within the \grammarterm{decl-specifier-seq} of a \grammarterm{member-declaration} is parsed as part of an \grammarterm{enum-base}. -\enternote This resolves a potential ambiguity between the declaration of an enumeration +\begin{note} This resolves a potential ambiguity between the declaration of an enumeration with an \grammarterm{enum-base} and the declaration of an unnamed bit-field of enumeration -type. \enterexample +type. \begin{example} \begin{codeblock} struct S { @@ -1863,8 +1863,8 @@ }; \end{codeblock} -\exitexample -\exitnote +\end{example} +\end{note} If an \grammarterm{opaque-enum-declaration} contains a \grammarterm{nested-name-specifier}, the declaration shall be an explicit specialization~(\ref{temp.expl.spec}). @@ -1898,7 +1898,7 @@ \grammarterm{initializer} gives the \grammarterm{enumerator} the value obtained by increasing the value of the previous \grammarterm{enumerator} by one. -\enterexample +\begin{example} \begin{codeblock} enum { a, b, c=0 }; @@ -1907,17 +1907,17 @@ defines \tcode{a}, \tcode{c}, and \tcode{d} to be zero, \tcode{b} and \tcode{e} to be \tcode{1}, and \tcode{f} to be \tcode{3}. -\exitexample +\end{example} The optional \grammarterm{attribute-specifier-seq} in an \grammarterm{enumerator} appertains to that enumerator. \pnum An \grammarterm{opaque-enum-declaration} is either a redeclaration of an enumeration in the current scope or a declaration of a new enumeration. -\enternote An enumeration declared by an +\begin{note} An enumeration declared by an \grammarterm{opaque-enum-declaration} has fixed underlying type and is a complete type. The list of enumerators can be provided in a later redeclaration -with an \grammarterm{enum-specifier}. \exitnote A scoped enumeration +with an \grammarterm{enum-specifier}. \end{note} A scoped enumeration shall not be later redeclared as unscoped or with a different underlying type. An unscoped enumeration shall not be later redeclared as scoped and each redeclaration shall include an \grammarterm{enum-base} specifying the same @@ -2023,7 +2023,7 @@ \pnum The value of an enumerator or an object of an unscoped enumeration type is converted to an integer by integral promotion~(\ref{conv.prom}). -\enterexample +\begin{example} \indextext{example!enumeration}% \begin{codeblock} @@ -2060,7 +2060,7 @@ if (y) { } // error: no \tcode{Col} to \tcode{bool} conversion \end{codeblock} -\exitexample +\end{example} \pnum \indextext{class!scope~of enumerator}% @@ -2069,7 +2069,7 @@ Each scoped \grammarterm{enumerator} is declared in the scope of the enumeration. These names obey the scope rules defined for all names -in~(\ref{basic.scope}) and~(\ref{basic.lookup}).\enterexample +in~(\ref{basic.scope}) and~(\ref{basic.lookup}).\begin{example} \begin{codeblock} enum direction { left='l', right='r' }; @@ -2088,12 +2088,12 @@ a = altitude::low; // OK } \end{codeblock} -\exitexample +\end{example} \indextext{member!enumerator}% An enumerator declared in class scope can be referred to using the class member access operators (\tcode{::}, \tcode{.} (dot) and \tcode{->} (arrow)), see~\ref{expr.ref}. -\enterexample +\begin{example} \begin{codeblock} struct X { @@ -2110,7 +2110,7 @@ // ... } \end{codeblock} -\exitexample +\end{example} \pnum If an \grammarterm{enum-head} contains a \grammarterm{nested-name-specifier}, @@ -2212,7 +2212,7 @@ \grammarterm{declaration}{s} in its \grammarterm{namespace-body} and a \grammarterm{namespace-definition} is itself a \grammarterm{declaration}, it follows that \grammarterm{namespace-definitions} can be nested. -\enterexample +\begin{example} \begin{codeblock} namespace Outer { @@ -2224,7 +2224,7 @@ } } \end{codeblock} -\exitexample +\end{example} \pnum The \term{enclosing namespaces} of a declaration are those @@ -2233,7 +2233,7 @@ (e.g., a definition as specified in~\ref{namespace.memdef}). Such a redeclaration has the same enclosing namespaces as the original declaration. -\enterexample +\begin{example} \begin{codeblock} namespace Q { namespace V { @@ -2247,7 +2247,7 @@ } } \end{codeblock} -\exitexample +\end{example} \pnum If the optional initial \tcode{inline} keyword appears in a @@ -2297,7 +2297,7 @@ \begin{codeblock} namespace E { namespace I { B } } \end{codeblock} -\enterexample +\begin{example} \begin{codeblock} namespace A::B::C { int i; @@ -2313,7 +2313,7 @@ } } \end{codeblock} -\exitexample +\end{example} \rSec3[namespace.unnamed]{Unnamed namespaces}% \indextext{namespace!unnamed} @@ -2337,7 +2337,7 @@ The optional \grammarterm{attribute-specifier-seq} in the \grammarterm{unnamed-namespace-definition} appertains to \uniquens{}. -\enterexample +\begin{example} \begin{codeblock} namespace { int i; } // \uniquens\tcode{::i} @@ -2358,7 +2358,7 @@ j++; // \tcode{A::}\uniquens\tcode{::j} } \end{codeblock} -\exitexample +\end{example} \rSec3[namespace.memdef]{Namespace member definitions}% \indextext{namespace!member definition} @@ -2367,12 +2367,12 @@ A declaration in a namespace \tcode{N} (excluding declarations in nested scopes) whose \grammarterm{declarator-id} is an \grammarterm{unqualified-id} declares (or redeclares) a member of \tcode{N}, and may be a definition. -\enternote An explicit instantiation~(\ref{temp.explicit}) or +\begin{note} An explicit instantiation~(\ref{temp.explicit}) or explicit specialization~(\ref{temp.expl.spec}) of a template does not introduce a name and thus may be declared using an \grammarterm{unqualified-id} in a member of the enclosing namespace set, -if the primary template is declared in an inline namespace. \exitnote -\enterexample +if the primary template is declared in an inline namespace. \end{note} +\begin{example} \begin{codeblock} namespace X { @@ -2385,7 +2385,7 @@ void g(); // error: conflicts with \tcode{X::M::g()} } \end{codeblock} -\exitexample +\end{example} \pnum Members of a named namespace can also be @@ -2394,7 +2394,7 @@ that the entity being defined was already declared in the namespace and the definition appears after the point of declaration in a namespace that encloses the declaration's namespace. -\enterexample +\begin{example} \begin{codeblock} namespace Q { @@ -2412,7 +2412,7 @@ void Q::V::g() { /* ... */ } // error: \tcode{R} doesn't enclose \tcode{Q} } \end{codeblock} -\exitexample +\end{example} \pnum If a \tcode{friend} declaration in a non-local class first declares a @@ -2420,10 +2420,10 @@ the friend is a member of the innermost enclosing namespace. The \tcode{friend} declaration does not by itself make the name visible to unqualified lookup~(\ref{basic.lookup.unqual}) or qualified -lookup~(\ref{basic.lookup.qual}). \enternote The name of the friend will be +lookup~(\ref{basic.lookup.qual}). \begin{note} The name of the friend will be visible in its namespace if a matching declaration is provided at namespace scope (either before or after the class definition granting friendship). -\exitnote If a friend +\end{note} If a friend function or function template is called, its name may be found by the name lookup that considers functions from namespaces and classes associated with the types of the function @@ -2432,11 +2432,11 @@ \grammarterm{template-id} and the declaration is a function or an \grammarterm{elaborated-type-specifier}, the lookup to determine whether the entity has been previously declared shall not consider any scopes -outside the innermost enclosing namespace. \enternote The other forms of +outside the innermost enclosing namespace. \begin{note} The other forms of \tcode{friend} declarations cannot declare a new member of the innermost enclosing namespace and thus follow the usual lookup rules. -\exitnote -\enterexample +\end{note} +\begin{example} \begin{codeblock} // Assume \tcode{f} and \tcode{g} have not yet been declared. @@ -2469,7 +2469,7 @@ A::X::Y::g(); // error: \tcode{g} is not a member of \tcode{A::X::Y} } \end{codeblock} -\exitexample +\end{example} \rSec2[namespace.alias]{Namespace alias}% \indextext{namespace!alias}% @@ -2500,18 +2500,18 @@ a synonym for the name of the namespace denoted by the \grammarterm{qualified-namespace-specifier} and becomes a \grammarterm{namespace-alias}. -\enternote +\begin{note} When looking up a \grammarterm{namespace-name} in a \grammarterm{namespace-alias-definition}, only namespace names are considered, see~\ref{basic.lookup.udir}. -\exitnote +\end{note} \pnum In a declarative region, a \grammarterm{namespace-alias-definition} can be used to redefine a \grammarterm{namespace-alias} declared in that declarative region to refer only to the namespace to which it already refers. -\enterexample +\begin{example} the following declarations are well-formed: \begin{codeblock} @@ -2520,7 +2520,7 @@ namespace CWVLN = Company_with_very_long_name; // OK: duplicate namespace CWVLN = CWVLN; \end{codeblock} -\exitexample +\end{example} \rSec2[namespace.udecl]{The \tcode{using} declaration}% \indextext{using-declaration|(} @@ -2542,11 +2542,11 @@ the \grammarterm{unqualified-id} is declared in the declarative region in which the \grammarterm{using-declaration} appears as a synonym for each declaration introduced by the \grammarterm{using-declaration}. -\enternote Only the specified name is so declared; +\begin{note} Only the specified name is so declared; specifying an enumeration name in a \grammarterm{using-declaration} does not declare its enumerators in the \grammarterm{using-declaration}{'s} declarative region. -\exitnote +\end{note} \indextext{inheritance!\idxgram{using-declaration}~and}% If the \grammarterm{using-declaration} names a constructor, it declares that the class \term{inherits} the set of constructor declarations @@ -2555,7 +2555,7 @@ \pnum Every \grammarterm{using-declaration} is a \grammarterm{declaration} and a \grammarterm{member-declaration} and so can be used in a class definition. -\enterexample +\begin{example} \begin{codeblock} struct B { @@ -2571,7 +2571,7 @@ void g(int) { g('c'); } // recursively calls \tcode{D::g(int)} }; \end{codeblock} -\exitexample +\end{example} \pnum In a \grammarterm{using-declaration} used as a @@ -2580,7 +2580,7 @@ \grammarterm{using-declaration} names a constructor, the \grammarterm{nested-name-specifier} shall name a direct base class of the class being defined. -\enterexample +\begin{example} \begin{codeblock} class C { @@ -2594,17 +2594,17 @@ using C::g; // error: \tcode{C} isn't a base of \tcode{D2} }; \end{codeblock} -\exitexample +\end{example} \pnum -\enternote +\begin{note} Since destructors do not have names, a \grammarterm{using-declaration} cannot refer to a destructor for a base class. Since specializations of member templates for conversion functions are not found by name lookup, they are not considered when a \grammarterm{using-declaration} specifies a conversion function~(\ref{temp.mem}). -\exitnote +\end{note} If a constructor or assignment operator brought from a base class into a derived class has the signature of a copy/move constructor or assignment operator for the derived class~(\ref{class.copy}), @@ -2616,7 +2616,7 @@ \pnum A \grammarterm{using-declaration} shall not name a \grammarterm{template-id}. -\enterexample +\begin{example} \begin{codeblock} struct A { @@ -2628,7 +2628,7 @@ using A::X; // ill-formed }; \end{codeblock} -\exitexample +\end{example} \pnum A \grammarterm{using-declaration} shall not name a namespace. @@ -2639,7 +2639,7 @@ \pnum A \grammarterm{using-declaration} that names a class member shall be a \grammarterm{member-declaration}. -\enterexample +\begin{example} \begin{codeblock} struct X { @@ -2654,13 +2654,13 @@ // and this is not a member declaration. } \end{codeblock} -\exitexample +\end{example} \pnum Members declared by a \grammarterm{using-declaration} can be referred to by explicit qualification just like other member names~(\ref{namespace.qual}). -\enterexample +\begin{example} \begin{codeblock} void f(); @@ -2680,13 +2680,13 @@ X::g(); // calls \tcode{A::g} } \end{codeblock} -\exitexample +\end{example} \pnum A \grammarterm{using-declaration} is a \grammarterm{declaration} and can therefore be used repeatedly where (and only where) multiple declarations are allowed. -\enterexample +\begin{example} \begin{codeblock} namespace A { @@ -2707,10 +2707,10 @@ using B::i; // error: double member declaration }; \end{codeblock} -\exitexample +\end{example} \pnum -\enternote +\begin{note} For a \grammarterm{using-declaration} that names a namespace, members added to the namespace after the \grammarterm{using-declaration} are not in the set of introduced declarations, so they are not @@ -2718,8 +2718,8 @@ overloads added after the \grammarterm{using-declaration} are ignored, but default function arguments~(\ref{dcl.fct.default}), default template arguments~(\ref{temp.param}), and template specializations~(\ref{temp.class.spec}, -\ref{temp.expl.spec}) are considered. \exitnote -\enterexample +\ref{temp.expl.spec}) are considered. \end{note} +\begin{example} \begin{codeblock} namespace A { @@ -2742,23 +2742,23 @@ f('a'); // calls \tcode{f(char)} } \end{codeblock} -\exitexample +\end{example} \pnum -\enternote +\begin{note} Partial specializations of class templates are found by looking up the primary class template and then considering all partial specializations of that template. If a \grammarterm{using-declaration} names a class template, partial specializations introduced after the \grammarterm{using-declaration} are effectively visible because the primary template is visible~(\ref{temp.class.spec}). -\exitnote +\end{note} \pnum Since a \grammarterm{using-declaration} is a declaration, the restrictions on declarations of the same name in the same declarative region~(\ref{basic.scope}) also apply to \grammarterm{using-declaration}{s}. -\enterexample +\begin{example} \begin{codeblock} namespace A { @@ -2789,7 +2789,7 @@ struct x x1; // \tcode{x1} has class type \tcode{B::x} } \end{codeblock} -\exitexample +\end{example} \pnum If a function declaration in namespace scope or block scope has the same @@ -2800,13 +2800,13 @@ the same name, parameter-type-list, return type, and template parameter list as a function template introduced by a \grammarterm{using-declaration}, the program is ill-formed. -\enternote +\begin{note} Two \grammarterm{using-declaration}{s} may introduce functions with the same name and the same parameter-type-list. If, for a call to an unqualified function name, function overload resolution selects the functions introduced by such \grammarterm{using-declaration}{s}, the function call is ill-formed. -\enterexample +\begin{example} \begin{codeblock} namespace B { @@ -2827,8 +2827,8 @@ void f(int); // error: \tcode{f(int)} conflicts with \tcode{C::f(int)} and \tcode{B::f(int)} } \end{codeblock} -\exitexample -\exitnote +\end{example} +\end{note} \pnum \indextext{name hiding!using-declaration and}% @@ -2840,7 +2840,7 @@ class (rather than conflicting). Such hidden or overridden declarations are excluded from the set of declarations introduced by the \grammarterm{using-declaration}. -\enterexample +\begin{example} \begin{codeblock} struct B { @@ -2890,7 +2890,7 @@ }; D2 d2(0); // calls \tcode{D2::D2(int)} \end{codeblock} -\exitexample +\end{example} \pnum \indextext{overloading!using-declaration and}% @@ -2922,7 +2922,7 @@ member function, then all functions named shall be accessible. The base class members mentioned by a \grammarterm{using-declaration} shall be visible in the scope of at least one of the direct base classes of the -class where the \grammarterm{using-declaration} is specified. \enternote +class where the \grammarterm{using-declaration} is specified. \begin{note} Because a \grammarterm{using-declaration} designates a base class member (and not a member subobject or a member function of a base class subobject), a \grammarterm{using-declaration} cannot be used to resolve @@ -2944,7 +2944,7 @@ return d->x(); // ambiguous: \tcode{B::x} or \tcode{C::x} } \end{codeblock} -\exitnote +\end{note} \pnum A synonym created by a \grammarterm{using-declaration} has the usual @@ -2954,7 +2954,7 @@ are accessible if they would be accessible when used to construct an object of the corresponding base class, and the accessibility of the \grammarterm{using-declaration} is ignored. -\enterexample +\begin{example} \begin{codeblock} class A { @@ -2972,7 +2972,7 @@ using A::g; // \tcode{B::g} is a public synonym for \tcode{A::g} }; \end{codeblock} -\exitexample +\end{example} \pnum If a \grammarterm{using-declaration} uses the keyword \tcode{typename} and @@ -2992,11 +2992,11 @@ \pnum A \grammarterm{using-directive} shall not appear in class scope, but may appear in namespace scope or in block scope. -\enternote +\begin{note} When looking up a \grammarterm{namespace-name} in a \grammarterm{using-directive}, only namespace names are considered, see~\ref{basic.lookup.udir}. -\exitnote +\end{note} The optional \grammarterm{attribute-specifier-seq} appertains to the \grammarterm{using-directive}. \pnum @@ -3007,14 +3007,14 @@ appear as if they were declared in the nearest enclosing namespace which contains both the \grammarterm{using-directive} and the nominated namespace. -\enternote +\begin{note} In this context, ``contains'' means ``contains directly or indirectly''. -\exitnote +\end{note} \pnum A \grammarterm{using-directive} does not add any members to the declarative region in which it appears. -\enterexample +\begin{example} \begin{codeblock} namespace A { @@ -3043,7 +3043,7 @@ i = 5; // ill-formed; neither \tcode{i} is visible } \end{codeblock} -\exitexample +\end{example} \pnum For unqualified lookup~(\ref{basic.lookup.unqual}), the @@ -3052,8 +3052,8 @@ contains \grammarterm{using-directive}{s}, the effect is as if the \grammarterm{using-directive}{s} from the second namespace also appeared in the first. -\enternote For qualified lookup, see~\ref{namespace.qual}. \exitnote -\enterexample +\begin{note} For qualified lookup, see~\ref{namespace.qual}. \end{note} +\begin{example} \begin{codeblock} namespace M { @@ -3095,7 +3095,7 @@ } } \end{codeblock} -\exitexample +\end{example} \pnum @@ -3110,7 +3110,7 @@ If name lookup finds a declaration for a name in two different namespaces, and the declarations do not declare the same entity and do not declare functions, the use of the name is ill-formed. -\enternote +\begin{note} In particular, the name of a variable, function or enumerator does not hide the name of a class or enumeration declared in a different namespace. For example, @@ -3135,19 +3135,19 @@ h(); // OK: overload resolution selects \tcode{A::h} } \end{codeblock} -\exitnote +\end{note} \pnum \indextext{overloading!using directive and}% During overload resolution, all functions from the transitive search are considered for argument matching. The set of declarations found by the transitive search is unordered. -\enternote +\begin{note} In particular, the order in which namespaces were considered and the relationships among the namespaces implied by the \grammarterm{using-directive}{s} do not cause preference to be given to any of the declarations found by the search. -\exitnote +\end{note} An ambiguity exists if the best match finds two functions with the same signature, even if one is in a namespace reachable through \grammarterm{using-directive}{s} in the namespace of the other.\footnote{During @@ -3156,7 +3156,7 @@ paths~(\ref{class.member.lookup}). There is no such disambiguation when considering the set of names found as a result of following \grammarterm{using-directive}{s}.} -\enterexample +\begin{example} \begin{codeblock} namespace D { @@ -3188,7 +3188,7 @@ f('a'); // OK: \tcode{D::f(char)} } \end{codeblock} -\exitexample% +\end{example}% \indextext{using-directive|)}% \indextext{namespaces|)} @@ -3207,10 +3207,10 @@ The \tcode{asm} declaration is conditionally-supported; its meaning is \impldef{meaning of \tcode{asm} declaration}. -\enternote +\begin{note} Typically it is used to pass information through the implementation to an assembler. -\exitnote +\end{note} \rSec1[dcl.link]{Linkage specifications}% \indextext{specification!linkage|(} @@ -3218,13 +3218,13 @@ \pnum All function types, function names with external linkage, and variable names with external linkage have a \term{language linkage}. -\enternote +\begin{note} Some of the properties associated with an entity with language linkage are specific to each implementation and are not described here. For example, a particular language linkage may be associated with a particular form of representing names of objects and functions with external linkage, or with a particular calling convention, etc. -\exitnote +\end{note} The default language linkage of all function types, function names, and variable names is \Cpp language linkage. Two function types with different language linkages are distinct types even if they are @@ -3248,16 +3248,16 @@ \grammarterm{string-literal}{s} \tcode{"C"} and \tcode{"C++"}. Use of a \grammarterm{string-literal} other than \tcode{"C"} or \tcode{"C++"} is conditionally-supported, with \impldef{semantics of linkage specifiers} semantics. -\enternote +\begin{note} Therefore, a linkage-specification with a \grammarterm{string-literal} that is unknown to the implementation requires a diagnostic. -\exitnote -\enternote +\end{note} +\begin{note} It is recommended that the spelling of the \grammarterm{string-literal} be taken from the document defining that language. For example, \tcode{Ada} (not \tcode{ADA}) and \tcode{Fortran} or \tcode{FORTRAN}, depending on the vintage. -\exitnote +\end{note} \pnum \indextext{specification!linkage!implementation-defined}% @@ -3265,7 +3265,7 @@ the C programming language, \indextext{C!linkage~to}% \tcode{"C"}, and linkage to \Cpp functions, \tcode{"C++"}. -\enterexample +\begin{example} \begin{codeblock} complex sqrt(complex); // \Cpp linkage by default @@ -3273,7 +3273,7 @@ double sqrt(double); // C linkage } \end{codeblock} -\exitexample +\end{example} \pnum \indextext{specification!linkage!nesting}% @@ -3285,7 +3285,7 @@ to the function types of all function declarators, function names with external linkage, and variable names with external linkage declared within the \grammarterm{linkage-specification}. -\enterexample +\begin{example} \begin{codeblock} extern "C" void f1(void(*pf)(int)); @@ -3325,13 +3325,13 @@ // previous declaration. } \end{codeblock} -\exitexample +\end{example} \indextext{class!linkage~specification}% A C language linkage is ignored in determining the language linkage of the names of class members and the function type of class member functions. -\enterexample +\begin{example} \begin{codeblock} extern "C" typedef void FUNC_c(); @@ -3356,7 +3356,7 @@ }; } \end{codeblock} -\exitexample +\end{example} \pnum If two declarations declare functions with the same name and @@ -3389,15 +3389,15 @@ function with C language linkage (ignoring the namespace names that qualify the respective names); no diagnostic is required if the declarations appear in different translation units. -\enternote +\begin{note} Only one definition for an entity with a given name with C language linkage may appear in the program (see~\ref{basic.def.odr}); this implies that such an entity must not be defined in more -than one namespace scope.\exitnote -\enterexample +than one namespace scope.\end{note} +\begin{example} \begin{codeblock} int x; @@ -3418,7 +3418,7 @@ extern "C" int h() { return 97; } // definition for the function \tcode{h} with C language linkage // \tcode{A::h} and \tcode{::h} refer to the same function \end{codeblock} -\exitexample +\end{example} \pnum A declaration directly contained in a @@ -3428,7 +3428,7 @@ specifier~(\ref{dcl.stc}) for the purpose of determining the linkage of the declared name and whether it is a definition. Such a declaration shall not specify a storage class. -\enterexample +\begin{example} \begin{codeblock} extern "C" double f(); @@ -3439,14 +3439,14 @@ } extern "C" static void g(); // error \end{codeblock} -\exitexample +\end{example} \pnum -\enternote +\begin{note} Because the language linkage is part of a function type, when indirecting through a pointer to C function, the function to which the resulting lvalue refers is considered a C function. -\exitnote +\end{note} \pnum \indextext{object!linkage~specification}% @@ -3534,8 +3534,8 @@ \end{bnf} \pnum -\enternote For each individual attribute, the form of the -\grammarterm{balanced-token-seq} will be specified. \exitnote +\begin{note} For each individual attribute, the form of the +\grammarterm{balanced-token-seq} will be specified. \end{note} \pnum In an \grammarterm{attribute-list}, an ellipsis may appear only if that @@ -3553,9 +3553,9 @@ \grammarterm{attribute-token}. The \grammarterm{attribute-token} determines additional requirements on the \grammarterm{attribute-argument-clause} (if any). The use of an \grammarterm{attribute-scoped-token} is conditionally-supported, with -\impldef{behavior of attribute scoped token} behavior. \enternote Each implementation +\impldef{behavior of attribute scoped token} behavior. \begin{note} Each implementation should choose a distinctive name for the \grammarterm{attribute-namespace} in an -\grammarterm{attribute-scoped-token}. \exitnote +\grammarterm{attribute-scoped-token}. \end{note} \pnum Each \grammarterm{attribute-specifier-seq} is said to \defn{appertain} to some entity or @@ -3578,9 +3578,9 @@ when introducing an \grammarterm{attribute-specifier} or within the \grammarterm{balanced-token-seq} of an \grammarterm{attribute-argument-clause}. -\enternote If two consecutive left square brackets appear +\begin{note} If two consecutive left square brackets appear where an \grammarterm{attribute-specifier} is not allowed, the program is ill-formed even -if the brackets match an alternative grammar production. \exitnote \enterexample +if the brackets match an alternative grammar production. \end{note} \begin{example} \begin{codeblock} int p[10]; void f() { @@ -3593,7 +3593,7 @@ int i [[vendor::attr([[]])]]; // well-formed implementation-defined attribute. } \end{codeblock} -\exitexample +\end{example} \rSec2[dcl.align]{Alignment specifier}% \indextext{attribute!alignment} @@ -3641,7 +3641,7 @@ be required for the entity being declared if all \grammarterm{alignment-specifier}{s} appertaining to that entity were omitted. -\enterexample +\begin{example} \begin{codeblock} struct alignas(8) S {}; struct alignas(1) U { @@ -3649,7 +3649,7 @@ }; // Error: \tcode{U} specifies an alignment that is less strict than // if the \tcode{alignas(1)} were omitted. \end{codeblock} -\exitexample +\end{example} \pnum If the defining declaration of an entity has an @@ -3664,7 +3664,7 @@ different \grammarterm{alignment-specifier}{s} in different translation units. -\enterexample +\begin{example} \begin{codeblock} // Translation unit \#1: struct S { int x; } s, *p = &s; @@ -3673,10 +3673,10 @@ struct alignas(16) S; // error: definition of \tcode{S} lacks alignment; no extern S* p; // diagnostic required \end{codeblock} -\exitexample +\end{example} \pnum -\enterexample An aligned buffer with an alignment requirement +\begin{example} An aligned buffer with an alignment requirement of \tcode{A} and holding \tcode{N} elements of type \tcode{T} can be declared as: @@ -3686,10 +3686,10 @@ Specifying \tcode{alignas(T)} ensures that the final requested alignment will not be weaker than \tcode{alignof(T)}, and therefore the program will not be ill-formed. -\exitexample +\end{example} \pnum -\enterexample +\begin{example} \begin{codeblock} alignas(double) void f(); // error: alignment applied to function alignas(double) unsigned char c[sizeof(double)]; // array of characters, suitably aligned for a \tcode{double} @@ -3697,7 +3697,7 @@ alignas(float) extern unsigned char c[sizeof(double)]; // error: different alignment in declaration \end{codeblock} -\exitexample +\end{example} \rSec2[dcl.attr.depend]{Carries dependency attribute}% \indextext{attribute!carries dependency} @@ -3728,11 +3728,11 @@ program is ill-formed; no diagnostic required. \pnum -\enternote The \tcode{carries_dependency} attribute does not change the meaning of the -program, but may result in generation of more efficient code. \exitnote +\begin{note} The \tcode{carries_dependency} attribute does not change the meaning of the +program, but may result in generation of more efficient code. \end{note} \pnum -\enterexample +\begin{example} \begin{codeblock} /* Translation unit A. */ @@ -3778,7 +3778,7 @@ implementation might need to insert a fence prior to the second call to \tcode{g}. -\exitexample% +\end{example}% \indextext{attribute|)}% \indextext{declaration|)} @@ -3787,17 +3787,17 @@ \pnum The \grammarterm{attribute-token} \tcode{deprecated} can be used to mark names and entities -whose use is still allowed, but is discouraged for some reason. \enternote in particular, +whose use is still allowed, but is discouraged for some reason. \begin{note} in particular, \tcode{deprecated} is appropriate for names and entities that are deemed obsolescent or -unsafe. \exitnote It shall appear at most once in each \grammarterm{attribute-list}. An +unsafe. \end{note} It shall appear at most once in each \grammarterm{attribute-list}. An \grammarterm{attribute-argument-clause} may be present and, if present, it shall have the form: \begin{codeblock} ( @\grammarterm{string-literal}@ ) \end{codeblock} -\enternote the \grammarterm{string-literal} in the \grammarterm{attribute-argument-clause} +\begin{note} the \grammarterm{string-literal} in the \grammarterm{attribute-argument-clause} could be used to explain the rationale for deprecation and/or to suggest a replacing entity. -\exitnote +\end{note} \pnum The attribute may be applied to the declaration of @@ -3813,19 +3813,19 @@ \pnum A name or entity declared without the \tcode{deprecated} attribute can later be re-declared -with the attribute and vice-versa. \enternote Thus, an entity initially declared without the +with the attribute and vice-versa. \begin{note} Thus, an entity initially declared without the attribute can be marked as deprecated by a subsequent redeclaration. However, after an entity -is marked as deprecated, later redeclarations do not un-deprecate the entity. \exitnote +is marked as deprecated, later redeclarations do not un-deprecate the entity. \end{note} Redeclarations using different forms of the attribute (with or without the \grammarterm{attribute-argument-clause} or with different \grammarterm{attribute-argument-clause}{s}) are allowed. \pnum -\enternote Implementations may use the \tcode{deprecated }attribute to produce a diagnostic +\begin{note} Implementations may use the \tcode{deprecated }attribute to produce a diagnostic message in case the program refers to a name or entity other than to declare it, after a declaration that specifies the attribute. The diagnostic message may include the text provided within the \grammarterm{attribute-argument-clause} of any \tcode{deprecated} attribute applied -to the name or entity. \exitnote +to the name or entity. \end{note} \rSec2[dcl.attr.fallthrough]{Fallthrough attribute} \indextext{attribute!fallthrough} @@ -3846,17 +3846,17 @@ The program is ill-formed if there is no such statement. \pnum -\enternote +\begin{note} The use of a fallthrough statement is intended to suppress a warning that an implementation might otherwise issue for a case or default label that is reachable from another case or default label along some path of execution. Implementations are encouraged to issue a warning if a fallthrough statement is not dynamically reachable. -\exitnote +\end{note} \pnum -\enterexample +\begin{example} \begin{codeblock} void f(int n) { void g(), h(), i(); @@ -3873,7 +3873,7 @@ } } \end{codeblock} -\exitexample +\end{example} \rSec2[dcl.attr.unused]{Maybe unused attribute}% \indextext{attribute!maybe unused} @@ -3890,11 +3890,11 @@ a function, an enumeration, or an enumerator. \pnum -\enternote +\begin{note} For an entity marked \tcode{maybe_unused}, implementations are encouraged not to emit a warning that the entity is unused, or that the entity is used despite the presence of the attribute. -\exitnote +\end{note} \pnum A name or entity declared without the \tcode{maybe_unused} attribute @@ -3904,7 +3904,7 @@ after the first declaration that marks it. \pnum -\enterexample +\begin{example} \begin{codeblock} [[maybe_unused]] void f([[maybe_unused]] bool thing1, [[maybe_unused]] bool thing2) { @@ -3914,7 +3914,7 @@ \end{codeblock} Implementations are encouraged not to warn that \tcode{b} is unused, whether or not \tcode{NDEBUG} is defined. -\exitexample +\end{example} \rSec2[dcl.attr.nodiscard]{Nodiscard attribute}% \indextext{attribute!nodiscard} @@ -3927,7 +3927,7 @@ no \grammarterm{attribute-argument-clause} shall be present. \pnum -\enternote +\begin{note} A nodiscard call is a function call expression that calls a function previously declared \tcode{nodiscard}, or whose return type is a possibly cv-qualified class or enumeration type @@ -3937,10 +3937,10 @@ Implementations are encouraged to issue a warning in such cases. This is typically because discarding the return value of a nodiscard call has surprising consequences. -\exitnote +\end{note} \pnum -\enterexample +\begin{example} \begin{codeblock} struct [[nodiscard]] error_info { /*...*/ }; error_info enable_missile_safety_mode(); @@ -3952,7 +3952,7 @@ error_info &foo(); void f() { foo(); } // reference type, warning not encouraged \end{codeblock} -\exitexample +\end{example} \rSec2[dcl.attr.noreturn]{Noreturn attribute}% \indextext{attribute!noreturn} @@ -3969,12 +3969,12 @@ \pnum If a function \tcode{f} is called where \tcode{f} was previously declared with the \tcode{noreturn} -attribute and \tcode{f} eventually returns, the behavior is undefined. \enternote The function may -terminate by throwing an exception. \exitnote \enternote Implementations are encouraged to issue a -warning if a function marked \tcode{[[noreturn]]} might return. \exitnote +attribute and \tcode{f} eventually returns, the behavior is undefined. \begin{note} The function may +terminate by throwing an exception. \end{note} \begin{note} Implementations are encouraged to issue a +warning if a function marked \tcode{[[noreturn]]} might return. \end{note} \pnum -\enterexample +\begin{example} \begin{codeblock} [[ noreturn ]] void f() { throw "error"; // OK @@ -3985,4 +3985,4 @@ throw "positive"; } \end{codeblock} -\exitexample +\end{example} diff --git a/source/declarators.tex b/source/declarators.tex index 6b71d0a97b..033499b1b7 100644 --- a/source/declarators.tex +++ b/source/declarators.tex @@ -233,7 +233,7 @@ in a declaration. The named type is then the same as the type of the hypothetical identifier. -\enterexample +\begin{example} \indextext{example!type~name}% \indextext{example!declarator}% @@ -260,7 +260,7 @@ (\tcode{double}) returning \tcode{int}''. -\exitexample +\end{example} \pnum A type can also be named (often more easily) by using a @@ -280,14 +280,14 @@ Just as for the ambiguities mentioned in~\ref{stmt.ambig}, the resolution is to consider any construct that could possibly be a declaration a declaration. -\enternote +\begin{note} A declaration can be explicitly disambiguated by a nonfunction-style cast, by an \tcode{=} to indicate initialization or by removing the redundant parentheses around the parameter name. -\exitnote -\enterexample +\end{note} +\begin{example} \begin{codeblock} struct S { @@ -301,7 +301,7 @@ S z = int(a); // object declaration } \end{codeblock} -\exitexample +\end{example} \pnum The ambiguity arising from the similarity between a function-style @@ -316,7 +316,7 @@ \grammarterm{type-id}. \pnum -\enterexample +\begin{example} \begin{codeblock} #include @@ -360,7 +360,7 @@ (int())1; // type-id (ill-formed) } \end{codeblock} -\exitexample +\end{example} \pnum Another ambiguity arises in a @@ -384,7 +384,7 @@ \grammarterm{simple-type-specifier} rather than a \grammarterm{declarator-id}. -\enterexample +\begin{example} \begin{codeblock} class C { }; @@ -406,7 +406,7 @@ void h(int *(C[10])); // \tcode{void h(int *(*_fp)(C _parm[10]));} // not: \tcode{void h(int *C[10]);} \end{codeblock} -\exitexample +\end{example} \rSec1[dcl.meaning]{Meaning of declarators}% \indextext{declarator!meaning~of|(} @@ -442,13 +442,13 @@ \grammarterm{declarator-id}. The \grammarterm{nested-name-specifier} of a qualified \grammarterm{declarator-id} shall not begin with a \grammarterm{decltype-specifier}. -\enternote +\begin{note} If the qualifier is the global \tcode{::} scope resolution operator, the \grammarterm{declarator-id} refers to a name declared in the global namespace scope. -\exitnote +\end{note} The optional \grammarterm{attribute-specifier-seq} following a \grammarterm{declarator-id} appertains to the entity that is declared. \pnum @@ -503,7 +503,7 @@ \tcode{T} determines the type \tcode{T}. -\enterexample +\begin{example} in the declaration \begin{codeblock} @@ -516,7 +516,7 @@ determine the type ``\tcode{unsigned int}'' (\ref{dcl.type.simple}). -\exitexample +\end{example} \pnum In a declaration @@ -587,7 +587,7 @@ Similarly, the optional \grammarterm{attribute-specifier-seq}~(\ref{dcl.attr.grammar}) appertains to the pointer and not to the object pointed to. \pnum -\enterexample +\begin{example} the declarations \indextext{example!\idxcode{const}}% \indextext{example!constant pointer}% @@ -654,20 +654,20 @@ // ... because of previous error *p = 5; // clobber \tcode{ci} \end{codeblock} -\exitexample +\end{example} \pnum See also~\ref{expr.ass} and~\ref{dcl.init}. \pnum -\enternote +\begin{note} Forming a pointer to reference type is ill-formed; see~\ref{dcl.ref}. Forming a function pointer type is ill-formed if the function type has \grammarterm{cv-qualifier}{s} or a \grammarterm{ref-qualifier}; see~\ref{dcl.fct}. Since the address of a bit-field (\ref{class.bit}) cannot be taken, a pointer can never point to a bit-field. -\exitnote +\end{note} \rSec2[dcl.ref]{References}% \indextext{declarator!reference} @@ -700,7 +700,7 @@ \grammarterm{typedef-name}~(\ref{dcl.typedef}, \ref{temp.param}) or \grammarterm{decltype-specifier}~(\ref{dcl.type.simple}), in which case the cv-qualifiers are ignored. -\enterexample +\begin{example} \begin{codeblock} typedef int& A; @@ -711,10 +711,10 @@ \tcode{aref} is ``lvalue reference to \tcode{int}'', not ``lvalue reference to \tcode{const int}''. -\exitexample -\enternote +\end{example} +\begin{note} A reference can be thought of as a name of an object. -\exitnote +\end{note} \indextext{\idxcode{void\&}}% A declarator that specifies the type ``reference to \textit{cv} \tcode{void}'' @@ -734,7 +734,7 @@ \pnum \indextext{declaration!reference}% \indextext{parameter!reference}% -\enterexample +\begin{example} \begin{codeblock} void f(double& a) { a += 3.14; } @@ -801,7 +801,7 @@ \tcode{q} with the value zero. See also~\ref{dcl.init.ref}. -\exitexample +\end{example} \pnum It is unspecified whether or not @@ -821,7 +821,7 @@ is a class member (\ref{class.mem}) declaration within a class definition, or is the declaration of a parameter or a return type (\ref{dcl.fct}); see~\ref{basic.def}. A reference shall be initialized to refer to a valid object or function. -\enternote +\begin{note} \indextext{reference!null}% in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to @@ -829,7 +829,7 @@ which causes undefined behavior. As described in~\ref{class.bit}, a reference cannot be bound directly to a bit-field. -\exitnote +\end{note} \pnum \indextext{reference collapsing}% @@ -837,7 +837,7 @@ or a \grammarterm{decltype-specifier}~(\ref{dcl.type.simple}) denotes a type \tcode{TR} that is a reference to a type \tcode{T}, an attempt to create the type ``lvalue reference to \cv\ \tcode{TR}'' creates the type ``lvalue reference to \tcode{T}'', while an attempt to create -the type ``rvalue reference to \cv\ \tcode{TR}'' creates the type \tcode{TR}. \enterexample +the type ``rvalue reference to \cv\ \tcode{TR}'' creates the type \tcode{TR}. \begin{example} \begin{codeblock} int i; @@ -854,13 +854,13 @@ decltype(r2)& r6 = i; // \tcode{r6} has the type \tcode{int\&} decltype(r2)&& r7 = i; // \tcode{r7} has the type \tcode{int\&} \end{codeblock} -\exitexample +\end{example} \pnum -\enternote Forming a reference to function type is ill-formed if the function +\begin{note} Forming a reference to function type is ill-formed if the function type has \grammarterm{cv-qualifier}{s} or a \grammarterm{ref-qualifier}; see~\ref{dcl.fct}. -\exitnote +\end{note} \rSec2[dcl.mptr]{Pointers to members}% \indextext{declarator!pointer to member} @@ -894,7 +894,7 @@ pointer-to-member. \pnum -\enterexample% +\begin{example}% \indextext{example!pointer~to~member} \begin{codeblock} @@ -957,7 +957,7 @@ (obj.*pmf)(7); // call a function member of \tcode{obj} // with the argument \tcode{7} \end{codeblock} -\exitexample +\end{example} \pnum A pointer to member shall not point to a static member @@ -967,13 +967,13 @@ ``\textit{cv} \tcode{void}''. -\enternote +\begin{note} See also~\ref{expr.unary} and~\ref{expr.mptr.oper}. The type ``pointer to member'' is distinct from the type ``pointer'', that is, a pointer to member is declared only by the pointer to member declarator syntax, and never by the pointer declarator syntax. There is no ``reference-to-member'' type in \Cpp. -\exitnote +\end{note} \rSec2[dcl.array]{Arrays}% \indextext{declarator!array} @@ -1061,22 +1061,22 @@ ``array of unknown bound of \tcode{T}''. The optional \grammarterm{attribute-specifier-seq} appertains to the array. -\enterexample +\begin{example} \begin{codeblock} typedef int A[5], AA[2][3]; typedef const A CA; // type is ``array of 5 \tcode{const int}'' typedef const AA CAA; // type is ``array of 2 array of 3 \tcode{const int}'' \end{codeblock} -\exitexample -\enternote +\end{example} +\begin{note} An ``array of \tcode{N} \nonterminal{cv-qualifier-seq} \tcode{T}'' has cv-qualified type; see~\ref{basic.type.qualifier}. -\exitnote +\end{note} \pnum An array can be constructed from one of the fundamental types @@ -1117,7 +1117,7 @@ of a static data member of a class. \pnum -\enterexample +\begin{example} \indextext{example!subscripting}% \indextext{example!array}% \begin{codeblock} @@ -1165,16 +1165,16 @@ int i = sizeof(x); // error: incomplete object type } \end{codeblock} -\exitexample +\end{example} \pnum -\enternote +\begin{note} conversions affecting expressions of array type are described in~\ref{conv.array}. Objects of array types cannot be modified, see~\ref{basic.lval}. -\exitnote +\end{note} \pnum -\enternote +\begin{note} Except where it has been declared for a class (\ref{over.sub}), the subscript operator \tcode{[]} @@ -1229,7 +1229,7 @@ which itself is immediately converted into a pointer. \pnum -\enterexample +\begin{example} consider \begin{codeblock} @@ -1263,18 +1263,18 @@ a pointer to the first of the integers. If there is another subscript the same argument applies again; this time the result is an integer. -\exitexample -\exitnote +\end{example} +\end{note} \pnum -\enternote +\begin{note} It follows from all this that arrays in \Cpp are stored row-wise (last subscript varies fastest) \indextext{array!storage~of}% and that the first subscript in the declaration helps determine the amount of storage consumed by an array but plays no other part in subscript calculations. -\exitnote +\end{note} \rSec2[dcl.fct]{Functions}% \indextext{declarator!function|(} @@ -1390,13 +1390,13 @@ The \grammarterm{parameter-declaration-clause} determines the arguments that can be specified, and their processing, when the function is called. -\enternote +\begin{note} \indextext{conversion!argument}% the \grammarterm{parameter-declaration-clause} is used to convert the arguments specified on the function call; see~\ref{expr.call}. -\exitnote +\end{note} \indextext{argument~list!empty}% If the \grammarterm{parameter-declaration-clause} @@ -1423,7 +1423,7 @@ ``\tcode{, ...}'' is synonymous with ``\tcode{...}''. -\enterexample +\begin{example} \indextext{example!ellipsis}% \indextext{example!variable parameter~list}% the declaration @@ -1443,14 +1443,14 @@ that can be converted to a \tcode{const} \tcode{char*} -\exitexample -\enternote +\end{example} +\begin{note} The standard header \tcode{} \indextext{\idxhdr{cstdarg}}% contains a mechanism for accessing arguments passed using the ellipsis (see~\ref{expr.call} and~\ref{support.runtime}). -\exitnote +\end{note} \pnum \indextext{overloading}% @@ -1480,9 +1480,9 @@ and the presence or absence of the ellipsis or a function parameter pack is the function's \grammarterm{parameter-type-list}. -\enternote This transformation does not affect the types of the parameters. +\begin{note} This transformation does not affect the types of the parameters. For example, \tcode{int(*)(const int p, decltype(p)*)} and -\tcode{int(*)(int, const int*)} are identical types. \exitnote +\tcode{int(*)(int, const int*)} are identical types. \end{note} \pnum A function type with a \grammarterm{cv-qualifier-seq} or a @@ -1503,7 +1503,7 @@ \item the \grammarterm{type-id} of a \grammarterm{template-argument} for a \grammarterm{type-parameter}~(\ref{temp.arg.type}). \end{itemize} -\enterexample +\begin{example} \begin{codeblock} typedef int FIC(int) const; @@ -1513,7 +1513,7 @@ }; FIC S::*pm = &S::f; // OK \end{codeblock} -\exitexample +\end{example} \pnum The effect of a @@ -1521,9 +1521,9 @@ in a function declarator is not the same as adding cv-qualification on top of the function type. In the latter case, the cv-qualifiers are ignored. -\enternote a function type that has a \grammarterm{cv-qualifier-seq} is not a -cv-qualified type; there are no cv-qualified function types. \exitnote -\enterexample +\begin{note} a function type that has a \grammarterm{cv-qualifier-seq} is not a +cv-qualified type; there are no cv-qualified function types. \end{note} +\begin{example} \begin{codeblock} typedef void F(); @@ -1531,7 +1531,7 @@ const F f; // OK: equivalent to: \tcode{void f();} }; \end{codeblock} -\exitexample +\end{example} \pnum The return type, the parameter-type-list, the \grammarterm{ref-qualifier}, @@ -1540,13 +1540,13 @@ but not the default arguments (\ref{dcl.fct.default}) or the exception specification (\ref{except.spec}), are part of the function type. -\enternote +\begin{note} Function types are checked during the assignments and initializations of pointers to functions, references to functions, and pointers to member functions. -\exitnote +\end{note} \pnum -\enterexample +\begin{example} \indextext{example!function declaration}% the declaration @@ -1558,7 +1558,7 @@ and returning \tcode{int} (\ref{dcl.type}). -\exitexample +\end{example} \pnum \indextext{function~return~type|see{return~type}}% @@ -1581,7 +1581,7 @@ \indextext{typedef!function}% A typedef of function type may be used to declare a function but shall not be used to define a function (\ref{dcl.fct.def}). -\enterexample +\begin{example} \begin{codeblock} typedef void F(); @@ -1589,22 +1589,22 @@ F fv { } // ill-formed void fv() { } // OK: definition of \tcode{fv} \end{codeblock} -\exitexample +\end{example} \pnum An identifier can optionally be provided as a parameter name; if present in a function definition (\ref{dcl.fct.def}), it names a parameter. -\enternote +\begin{note} In particular, parameter names are also optional in function definitions and names used for a parameter in different declarations and the definition of a function need not be the same. If a parameter name is present in a function declaration that is not a definition, it cannot be used outside of its function declarator because that is the extent of its potential scope~(\ref{basic.scope.proto}). -\exitnote +\end{note} \pnum -\enterexample +\begin{example} the declaration \indextext{example!declaration}% @@ -1653,8 +1653,8 @@ \tcode{(*pif)(const char*, const char*)}, the extra parentheses are necessary to indicate that indirection through a pointer to a function yields a function, which is then called. -\exitexample -\enternote +\end{example} +\begin{note} Typedefs and \grammarterm{trailing-return-type}{s} are sometimes convenient when the return type of a function is complex. For example, the function @@ -1683,11 +1683,11 @@ \begin{codeblock} template decltype((*(T*)0) + (*(U*)0)) add(T t, U u); \end{codeblock} -\exitnote +\end{note} \pnum A \term{non-template function} is a function that is not a function template -specialization. \enternote A function template is not a function. \exitnote +specialization. \begin{note} A function template is not a function. \end{note} \pnum A \grammarterm{declarator-id} or \grammarterm{abstract-declarator} @@ -1696,12 +1696,12 @@ \grammarterm{parameter-declaration} is a parameter pack~(\ref{temp.variadic}). When it is part of a \grammarterm{parameter-declaration-clause}, the parameter pack is a -function parameter pack~(\ref{temp.variadic}). \enternote +function parameter pack~(\ref{temp.variadic}). \begin{note} Otherwise, the \grammarterm{parameter-declaration} is part of a \grammarterm{template-parameter-list} and the parameter pack is a -template parameter pack; see~\ref{temp.param}. \exitnote +template parameter pack; see~\ref{temp.param}. \end{note} A function parameter pack is a pack expansion~(\ref{temp.variadic}). -\enterexample +\begin{example} \begin{codeblock} template void f(T (* ...t)(int, int)); @@ -1713,7 +1713,7 @@ f(add, subtract); } \end{codeblock} -\exitexample +\end{example} \pnum There is a syntactic ambiguity when an ellipsis occurs at the end @@ -1741,7 +1741,7 @@ \pnum \indextext{argument!example~of default}% -\enterexample +\begin{example} the declaration \begin{codeblock} @@ -1761,7 +1761,7 @@ and \tcode{point(3,4)}, respectively. -\exitexample +\end{example} \pnum A default argument shall be specified only in the @@ -1806,7 +1806,7 @@ A default argument shall not be redefined by a later declaration (not even to the same value). -\enterexample +\begin{example} \begin{codeblock} void g(int = 0, ...); // OK, ellipsis is not a parameter so it can follow @@ -1830,7 +1830,7 @@ f(6); // OK, calls \tcode{f(6, 7)} } \end{codeblock} -\exitexample +\end{example} For a given inline function defined in different translation units, the accumulated sets of default arguments at the end of the translation units shall be the same; @@ -1853,7 +1853,7 @@ Name lookup and checking of semantic constraints for default arguments in function templates and in member functions of class templates are performed as described in~\ref{temp.inst}. -\enterexample +\begin{example} in the following code, \indextext{argument!example~of default}% \tcode{g} @@ -1873,14 +1873,14 @@ } } \end{codeblock} -\exitexample -\enternote +\end{example} +\begin{note} In member function declarations, names in default arguments are looked up as described in~\ref{basic.lookup.unqual}. Access checking applies to names in default arguments as described in Clause~\ref{class.access}. -\exitnote +\end{note} \pnum Except for member functions of class templates, the @@ -1894,7 +1894,7 @@ Default arguments for a member function of a class template shall be specified on the initial declaration of the member function within the class template. -\enterexample +\begin{example} \begin{codeblock} class C { @@ -1907,12 +1907,12 @@ void C::g(int i = 88, int j) { // in this translation unit, } // \tcode{C::g} can be called with no argument \end{codeblock} -\exitexample +\end{example} \pnum A local variable shall not appear as a potentially-evaluated expression in a default argument. -\enterexample +\begin{example} \begin{codeblock} void f() { @@ -1922,23 +1922,23 @@ // ... } \end{codeblock} -\exitexample +\end{example} \pnum -\enternote +\begin{note} The keyword \tcode{this} may not appear in a default argument of a member function; see~\ref{expr.prim.general}. -\enterexample +\begin{example} \begin{codeblock} class A { void f(A* p = this) { } // error }; \end{codeblock} -\exitexample -\exitnote +\end{example} +\end{note} \pnum \indextext{argument!evaluation~of default}% @@ -1950,7 +1950,7 @@ \indextext{argument~and~name~hiding!default}% Parameters of a function declared before a default argument are in scope and can hide namespace and class member names. -\enterexample +\begin{example} \begin{codeblock} int a; @@ -1960,11 +1960,11 @@ int g(float I, int b = I(2)); // error: parameter \tcode{I} found int h(int a, int b = sizeof(a)); // OK, unevaluated operand \end{codeblock} -\exitexample +\end{example} A non-static member shall not appear in a default argument unless it appears as the \grammarterm{id-expression} of a class member access expression (\ref{expr.ref}) or unless it is used to form a pointer to member (\ref{expr.unary.op}). -\enterexample +\begin{example} the declaration of \tcode{X::mem1()} in the following example is ill-formed because no object is supplied for the @@ -1988,10 +1988,10 @@ is meaningful, however, since no object is needed to access the static member \tcode{X::b}. Classes, objects, and members are described in Clause~\ref{class}. -\exitexample +\end{example} A default argument is not part of the type of a function. -\enterexample +\begin{example} \begin{codeblock} int f(int = 0); @@ -2004,7 +2004,7 @@ int (*p1)(int) = &f; int (*p2)() = &f; // error: type mismatch \end{codeblock} -\exitexample +\end{example} When a declaration of a function is introduced by way of a \grammarterm{using-declaration} (\ref{namespace.udecl}), any default argument information associated @@ -2024,7 +2024,7 @@ object. An overriding function in a derived class does not acquire default arguments from the function it overrides. -\enterexample +\begin{example} \begin{codeblock} struct A { @@ -2040,7 +2040,7 @@ pb->f(); // error: wrong number of arguments for \tcode{B::f()} } \end{codeblock} -\exitexample% +\end{example}% \indextext{declaration!default argument|)}% \indextext{declarator!meaning~of|)} @@ -2090,7 +2090,7 @@ A function shall be defined only in namespace or class scope. \pnum -\enterexample +\begin{example} a simple example of a complete function definition is \indextext{example!function definition}% @@ -2116,7 +2116,7 @@ \tcode{\{ /* ... */ \}} is the \grammarterm{function-body}. -\exitexample +\end{example} \pnum \indextext{initializer!base~class}% @@ -2127,13 +2127,13 @@ is used only in a constructor; see~\ref{class.ctor} and~\ref{class.init}. \pnum -\enternote +\begin{note} A \grammarterm{cv-qualifier-seq} affects the type of \tcode{this} in the body of a member function; see~\ref{dcl.ref}. -\exitnote +\end{note} \pnum -\enternote +\begin{note} Unused parameters need not be named. For example, @@ -2143,7 +2143,7 @@ std::printf("a = %d\n",a); } \end{codeblock} -\exitnote +\end{note} \pnum In the \grammarterm{function-body}, a @@ -2165,7 +2165,7 @@ implementation~(\ref{lex.name}). If a predefined variable is not odr-used~(\ref{basic.def.odr}), its string value need not be present in the program image.} -\enterexample +\begin{example} \begin{codeblock} struct S { S() : s(__func__) { } // OK @@ -2173,7 +2173,7 @@ }; void f(const char* s = __func__); // error: \tcode{__func__} is undeclared \end{codeblock} -\exitexample +\end{example} \rSec2[dcl.fct.def.default]{Explicitly-defaulted functions}% \indextext{definition!function!explicitly-defaulted} @@ -2224,7 +2224,7 @@ \end{itemize} \pnum -\enterexample +\begin{example} \begin{codeblock} struct S { constexpr S() = default; // ill-formed: implicit \tcode{S()} is not \tcode{constexpr} @@ -2237,7 +2237,7 @@ }; S::S(S&) = default; // OK: defines copy constructor \end{codeblock} -\exitexample +\end{example} \pnum Explicitly-defaulted functions and implicitly-declared functions are collectively @@ -2251,14 +2251,14 @@ (i.e., explicitly defaulted after its first declaration) is defined at the point where it is explicitly defaulted; if such a function is implicitly defined as deleted, the program is ill-formed. -\enternote +\begin{note} Declaring a function as defaulted after its first declaration can provide efficient execution and concise definition while enabling a stable binary interface to an evolving code -base.\exitnote +base.\end{note} \pnum -\enterexample +\begin{example} \begin{codeblock} struct trivial { @@ -2275,7 +2275,7 @@ }; nontrivial1::nontrivial1() = default; // not first declaration \end{codeblock} -\exitexample +\end{example} \rSec2[dcl.fct.def.delete]{Deleted definitions}% \indextext{definition!function!deleted} @@ -2292,16 +2292,16 @@ \pnum A program that refers to a deleted function implicitly or explicitly, other -than to declare it, is ill-formed. \enternote This includes calling the function +than to declare it, is ill-formed. \begin{note} This includes calling the function implicitly or explicitly and forming a pointer or pointer-to-member to the function. It applies even for references in expressions that are not potentially-evaluated. If a function is overloaded, it is referenced only if the function is selected by overload resolution. The implicit odr-use~(\ref{basic.def.odr}) of a virtual function does not, by itself, -constitute a reference. \exitnote +constitute a reference. \end{note} \pnum -\enterexample One can enforce non-default initialization and non-integral +\begin{example} One can enforce non-default initialization and non-integral initialization with \begin{codeblock} @@ -2312,9 +2312,9 @@ }; \end{codeblock} -\exitexample +\end{example} -\enterexample One can prevent use of a +\begin{example} One can prevent use of a class in certain \grammarterm{new-expression}{s} by using deleted definitions of a user-declared \tcode{operator new} for that class. @@ -2326,9 +2326,9 @@ sometype* p = new sometype; // error, deleted class \tcode{operator new} sometype* q = new sometype[3]; // error, deleted class \tcode{operator new[]} \end{codeblock} -\exitexample +\end{example} -\enterexample One can make a class uncopyable, i.e. move-only, by using deleted +\begin{example} One can make a class uncopyable, i.e. move-only, by using deleted definitions of the copy constructor and copy assignment operator, and then providing defaulted definitions of the move constructor and move assignment operator. @@ -2344,22 +2344,22 @@ moveonly* p; moveonly q(*p); // error, deleted copy constructor \end{codeblock} -\exitexample +\end{example} \pnum -A deleted function is implicitly an inline function~(\ref{dcl.fct.spec}). \enternote The -one-definition rule~(\ref{basic.def.odr}) applies to deleted definitions. \exitnote +A deleted function is implicitly an inline function~(\ref{dcl.fct.spec}). \begin{note} The +one-definition rule~(\ref{basic.def.odr}) applies to deleted definitions. \end{note} A deleted definition of a function shall be the first declaration of the function or, for an explicit specialization of a function template, the first declaration of that specialization. -\enterexample +\begin{example} \begin{codeblock} struct sometype { sometype(); }; sometype::sometype() = delete; // ill-formed; not first declaration \end{codeblock} -\exitexample% +\end{example}% \indextext{definition!function|)} \rSec1[dcl.init]{Initializers}% @@ -2421,7 +2421,7 @@ expressions involving literals and previously declared variables and functions, regardless of the variable's storage duration. -\enterexample +\begin{example} \begin{codeblock} int f(int); @@ -2429,16 +2429,16 @@ int b = f(a); int c(b); \end{codeblock} -\exitexample +\end{example} \pnum -\enternote +\begin{note} Default arguments are more restricted; see~\ref{dcl.fct.default}. \pnum The order of initialization of variables with static storage duration is described in~\ref{basic.start} and~\ref{stmt.dcl}. -\exitnote +\end{note} \pnum A declaration of a block-scope variable with external or internal @@ -2575,12 +2575,12 @@ of reference type is ill-formed. \pnum -\enternote Every +\begin{note} Every object of static storage duration is zero-initialized at program startup before any other initialization takes place. In some cases, additional initialization is done later. -\exitnote +\end{note} \pnum An object whose initializer is an empty set of parentheses, i.e., @@ -2589,7 +2589,7 @@ value-initialized. \indextext{ambiguity!function declaration}% -\enternote +\begin{note} Since \tcode{()} is not permitted by the syntax for @@ -2607,7 +2607,7 @@ \tcode{()} is permitted in certain other initialization contexts (\ref{expr.new}, \ref{expr.type.conv}, \ref{class.base.init}). -\exitnote +\end{note} \pnum \indextext{value!indeterminate}% @@ -2617,8 +2617,8 @@ is obtained, the object has an \term{indeterminate value}, and if no initialization is performed for the object, that object retains an indeterminate value until that value is replaced~(\ref{expr.ass}). -\enternote Objects with static or thread storage duration are zero-initialized, -see~\ref{basic.start.static}. \exitnote +\begin{note} Objects with static or thread storage duration are zero-initialized, +see~\ref{basic.start.static}. \end{note} If an indeterminate value is produced by an evaluation, the behavior is undefined except in the following cases: @@ -2649,7 +2649,7 @@ unsigned narrow character type, that object is initialized to an indeterminate value. \end{itemize} -\enterexample +\begin{example} \begin{codeblock} int f(bool b) { unsigned char c; @@ -2658,12 +2658,12 @@ return b ? d : 0; // undefined behavior if \tcode{b} is \tcode{true} } \end{codeblock} -\exitexample +\end{example} \pnum \indextext{initialization!class~member}% An initializer for a static member is in the scope of the member's class. -\enterexample +\begin{example} \begin{codeblock} int a; @@ -2676,7 +2676,7 @@ int X::a = 1; int X::b = a; // \tcode{X::b = X::a} \end{codeblock} -\exitexample +\end{example} \pnum If the entity being initialized does not have class type, the @@ -2695,7 +2695,7 @@ and aggregate member initialization~(\ref{dcl.init.aggr}), is called \defn{copy-initialization}. -\enternote Copy-initialization may invoke a move~(\ref{class.copy}). \exitnote +\begin{note} Copy-initialization may invoke a move~(\ref{class.copy}). \end{note} \pnum The initialization that occurs in the forms @@ -2805,7 +2805,7 @@ resulting value of the bit-field is \impldef{value of bit-field that cannot represent!initializer}. \indextext{initialization!\idxcode{const}}% -\enternote +\begin{note} An expression of type ``\nonterminal{cv1} \tcode{T}'' can initialize an object of type @@ -2820,7 +2820,7 @@ const int b = a; int c = b; \end{codeblock} -\exitnote +\end{note} \end{itemize} \pnum @@ -2849,10 +2849,10 @@ \item no virtual, private, or protected base classes~(\ref{class.mi}). \end{itemize} -\enternote +\begin{note} Aggregate initialization does not allow accessing protected and private base class' members or constructors. -\exitnote +\end{note} \pnum \indextext{aggregate!elements}% @@ -2875,10 +2875,10 @@ If the \grammarterm{initializer-clause} is an expression and a narrowing conversion~(\ref{dcl.init.list}) is required to convert the expression, the program is ill-formed. -\enternote If an \grammarterm{initializer-clause} is itself an initializer list, +\begin{note} If an \grammarterm{initializer-clause} is itself an initializer list, the element is list-initialized, which will result in a recursive application -of the rules in this section if the element is an aggregate. \exitnote -\enterexample +of the rules in this section if the element is an aggregate. \end{note} +\begin{example} \begin{codeblock} struct A { int x; @@ -2920,7 +2920,7 @@ \tcode{d2.b2} with 42, \tcode{d2.b3} with 42, \tcode{d2.d} with 4. -\exitexample +\end{example} \pnum An aggregate that is a class can also be initialized with a single @@ -2938,7 +2938,7 @@ shall be greater than zero, is defined as having \tcode{n} elements (\ref{dcl.array}). -\enterexample +\begin{example} \begin{codeblock} int x[] = { 1, 3, 5 }; @@ -2948,7 +2948,7 @@ \tcode{x} as a one-dimensional array that has three elements since no size was specified and there are three initializers. -\exitexample +\end{example} An empty initializer list \tcode{\{\}} shall not be used as the \grammarterm{initializer-clause } @@ -2959,7 +2959,7 @@ \pnum Static data members and anonymous bit-fields are not considered members of the class for purposes of aggregate initialization. -\enterexample +\begin{example} \begin{codeblock} struct A { @@ -2976,7 +2976,7 @@ and not the static data member \tcode{A::s}, and the third initializer 3 initializes \tcode{a.k} and not the anonymous bit-field before it. -\exitexample +\end{example} \pnum An @@ -2984,14 +2984,14 @@ is ill-formed if the number of \grammarterm{initializer-clause}{s} exceeds the number of members or elements to initialize. -\enterexample +\begin{example} \begin{codeblock} char cv[4] = { 'a', 's', 'd', 'f', 0 }; // error \end{codeblock} is ill-formed. -\exitexample +\end{example} \pnum If there are fewer \grammarterm{initializer-clause}{s} in the list than there @@ -2999,7 +2999,7 @@ shall be initialized from its default member initializer~(\ref{class.mem}) or, if there is no default member initializer, from an empty initializer list~(\ref{dcl.init.list}). -\enterexample +\begin{example} \begin{codeblock} struct S { int a; const char* b; int c; int d = b[a]; }; @@ -3024,14 +3024,14 @@ \end{codeblock} \tcode{a} and \tcode{b} have the same value -\exitexample +\end{example} \pnum If a reference member is initialized from its default member initializer and a potentially-evaluated subexpression thereof is an aggregate initialization that would use that default member initializer, the program is ill-formed. -\enterexample +\begin{example} \begin{codeblock} struct A; extern A a; @@ -3041,7 +3041,7 @@ }; A a{a,a}; // OK \end{codeblock} -\exitexample +\end{example} \pnum If an aggregate class \tcode{C} contains a subaggregate element @@ -3050,7 +3050,7 @@ omitted from an \grammarterm{initializer-list} for an object of type \tcode{C} unless the \grammarterm{initializer-clause}{s} for all elements of \tcode{C} following \tcode{e} are also omitted. -\enterexample +\begin{example} \begin{codeblock} struct S { } s; @@ -3068,7 +3068,7 @@ 0 }; // Initialization not required for \tcode{A::s3} because \tcode{A::i3} is also not initialized \end{codeblock} -\exitexample +\end{example} \pnum If an incomplete or empty @@ -3081,7 +3081,7 @@ \grammarterm{initializer-clause}{s} initialize the elements with the last (rightmost) index of the array varying the fastest (\ref{dcl.array}). -\enterexample +\begin{example} \begin{codeblock} int x[2][2] = { 3, 1, 4, 2 }; @@ -3113,7 +3113,7 @@ \tcode{y} (regarded as a two-dimensional array) and leaves the rest zero. -\exitexample +\end{example} \pnum Braces can be elided in an @@ -3138,7 +3138,7 @@ \grammarterm{initializer-clause}{s} are left to initialize the next element of the aggregate of which the current subaggregate is an element. -\enterexample +\begin{example} \begin{codeblock} float y[4][3] = { @@ -3192,7 +3192,7 @@ \tcode{y[1]} and \tcode{y[2]}. -\exitexample +\end{example} \pnum All implicit type conversions (Clause~\ref{conv}) are considered when @@ -3204,12 +3204,12 @@ brace elision is assumed and the \grammarterm{assignment-expression} is considered for the initialization of the first element of the subaggregate. -\enternote As specified above, brace elision cannot apply to +\begin{note} As specified above, brace elision cannot apply to subaggregates with no elements for purposes of aggregate initialization; an \grammarterm{initializer-clause} for the entire subobject is -required.\exitnote +required.\end{note} -\enterexample +\begin{example} \begin{codeblock} struct A { @@ -3237,22 +3237,22 @@ is initialized with whatever \tcode{a.operator int()} returns. -\exitexample +\end{example} \pnum \indextext{initialization!array~of class~objects}% -\enternote +\begin{note} An aggregate array or an aggregate class may contain elements of a class type with a user-provided constructor (\ref{class.ctor}). Initialization of these aggregate objects is described in~\ref{class.expl.init}. -\exitnote +\end{note} \pnum -\enternote +\begin{note} Whether the initialization of aggregates with static storage duration is static or dynamic is specified in~\ref{basic.start.static}, \ref{basic.start.dynamic}, and~\ref{stmt.dcl}. -\exitnote +\end{note} \pnum \indextext{initialization!\idxcode{union}}% @@ -3260,7 +3260,7 @@ the braces shall only contain an \grammarterm{initializer-clause} for the first non-static data member of the union. -\enterexample +\begin{example} \begin{codeblock} union u { int a; const char* b; }; @@ -3270,16 +3270,16 @@ u d = { 0, "asdf" }; // error u e = { "asdf" }; // error \end{codeblock} -\exitexample +\end{example} \pnum -\enternote +\begin{note} As described above, the braces around the \grammarterm{initializer-clause} for a union member can be omitted if the union is a member of another aggregate. -\exitnote +\end{note} \rSec2[dcl.init.string]{Character arrays}% \indextext{initialization!character array} @@ -3299,7 +3299,7 @@ characters of the value of the string literal initialize the elements of the array. -\enterexample +\begin{example} \begin{codeblock} char msg[] = "Syntax error on line %s\n"; @@ -3317,11 +3317,11 @@ \tcode{sizeof(msg)} is \tcode{25}. -\exitexample +\end{example} \pnum There shall not be more initializers than there are array elements. -\enterexample +\begin{example} \begin{codeblock} char cv[4] = "asdf"; // error @@ -3329,7 +3329,7 @@ is ill-formed since there is no space for the implied trailing \tcode{'\textbackslash 0'}. -\exitexample +\end{example} \pnum If there are fewer initializers than there are array elements, each element not @@ -3342,7 +3342,7 @@ A variable whose declared type is ``reference to type \tcode{T}'' (\ref{dcl.ref}) shall be initialized. -\enterexample +\begin{example} \begin{codeblock} int g(int) noexcept; @@ -3359,14 +3359,14 @@ ra[1] = i; // modifies \tcode{a[1]} } \end{codeblock} -\exitexample +\end{example} \pnum A reference cannot be changed to refer to another object after initialization. \indextext{assignment!reference}% -\enternote +\begin{note} Assignment to a reference assigns to the object referred to by the reference (\ref{expr.ass}). -\exitnote +\end{note} \indextext{argument~passing!reference~and}% Argument passing (\ref{expr.call}) \indextext{\idxcode{return}!reference~and}% @@ -3379,13 +3379,13 @@ \tcode{extern} specifier is explicitly used. \indextext{declaration!extern@\tcode{extern} reference}% -\enterexample +\begin{example} \begin{codeblock} int& r1; // error: initializer missing extern int& r2; // OK \end{codeblock} -\exitexample +\end{example} \pnum Given types ``\nonterminal{cv1} \tcode{T1}'' and ``\nonterminal{cv2} \tcode{T2}'', @@ -3447,14 +3447,14 @@ then the reference is bound to the initializer expression lvalue in the first case and to the lvalue result of the conversion in the second case (or, in either case, to the appropriate base class subobject of the object). -\enternote +\begin{note} The usual lvalue-to-rvalue (\ref{conv.lval}), array-to-pointer (\ref{conv.array}), and function-to-pointer (\ref{conv.func}) standard conversions are not needed, and therefore are suppressed, when such direct bindings to lvalues are done. -\exitnote +\end{note} -\enterexample +\begin{example} \begin{codeblock} double d = 2.0; @@ -3467,7 +3467,7 @@ const A& rca = b; // \tcode{rca} refers to \tcode{A} subobject in \tcode{b} int& ir = B(); // \tcode{ir} refers to the result of \tcode{B::operator int\&} \end{codeblock} -\exitexample +\end{example} \item Otherwise, the reference shall be an lvalue reference to a non-volatile @@ -3475,14 +3475,14 @@ \textit{cv1} shall be \tcode{const}), or the reference shall be an rvalue reference. -\enterexample +\begin{example} \begin{codeblock} double& rd2 = 2.0; // error: not an lvalue and reference not \tcode{const} int i = 2; double& rd3 = i; // error: type mismatch and reference not \tcode{const} \end{codeblock} -\exitexample +\end{example} \begin{itemize} \item If the initializer expression @@ -3504,7 +3504,7 @@ case and to the result of the conversion in the second case (or, in either case, to an appropriate base class subobject). -\enterexample +\begin{example} \begin{codeblock} struct A { }; @@ -3521,7 +3521,7 @@ int&& rri = static_cast(i2); // bound directly to \tcode{i2} B&& rrb = x; // bound directly to the result of \tcode{operator B} \end{codeblock} -\exitexample +\end{example} \item Otherwise: @@ -3560,7 +3560,7 @@ the initializer expression shall not be an lvalue. \end{itemize} -\enterexample +\begin{example} \begin{codeblock} struct Banana { }; struct Enigma { operator const Banana(); }; @@ -3586,7 +3586,7 @@ int i3 = 2; double&& rrd3 = i3; // \tcode{rrd3} refers to temporary with value \tcode{2.0} \end{codeblock} -\exitexample +\end{example} \end{itemize} \end{itemize} @@ -3595,9 +3595,9 @@ initializer expression. \pnum -\enternote +\begin{note} \ref{class.temporary} describes the lifetime of temporaries bound to references. -\exitnote +\end{note} \rSec2[dcl.init.list]{List-initialization}% \indextext{initialization!list-initialization|(} @@ -3610,7 +3610,7 @@ List-initialization can occur in direct-initialization or copy-initialization contexts; list-initialization in a direct-initialization context is called \grammarterm{direct-list-initialization} and list-initialization in a -copy-initialization context is called \grammarterm{copy-list-initialization}. \enternote +copy-initialization context is called \grammarterm{copy-list-initialization}. \begin{note} List-initialization can be used \begin{itemize} @@ -3626,7 +3626,7 @@ \item on the right-hand side of an assignment (\ref{expr.ass}) \end{itemize} -\enterexample +\begin{example} \begin{codeblock} int a = {1}; std::complex z{1,2}; @@ -3637,18 +3637,18 @@ x = double{1}; // explicitly construct a double std::map anim = { {"bear",4}, {"cassowary",2}, {"tiger",7} }; \end{codeblock} -\exitexample \exitnote +\end{example} \end{note} \pnum A constructor is an \grammarterm{initializer-list constructor} if its first parameter is of type \tcode{std::initializer_list} or reference to possibly cv-qualified \tcode{std::initializer_list} for some type \tcode{E}, and either there are no other parameters or else all other parameters have default arguments (\ref{dcl.fct.default}). -\enternote Initializer-list constructors are favored over other constructors in +\begin{note} Initializer-list constructors are favored over other constructors in list-initialization~(\ref{over.match.list}). Passing an initializer list as the argument to the constructor template \tcode{template C(T)} of a class \tcode{C} does not create an initializer-list constructor, because an initializer list argument causes the -corresponding parameter to be a non-deduced context~(\ref{temp.deduct.call}). \exitnote +corresponding parameter to be a non-deduced context~(\ref{temp.deduct.call}). \end{note} The template \tcode{std::initializer_list} is not predefined; if the header \tcode{} is not included prior to a use of @@ -3673,7 +3673,7 @@ \item Otherwise, if \tcode{T} is an aggregate, aggregate initialization is performed~(\ref{dcl.init.aggr}). -\enterexample +\begin{example} \begin{codeblock} double ad[] = { 1, 2.0 }; // OK int ai[] = { 1, 2.0 }; // error: narrowing @@ -3686,7 +3686,7 @@ S2 s22 { 1.0, 2, 3 }; // error: narrowing S2 s23 { }; // OK: default to 0,0,0 \end{codeblock} -\exitexample +\end{example} \item Otherwise, if the initializer list has no elements and \tcode{T} is a class type with a default constructor, the object is value-initialized. @@ -3702,7 +3702,7 @@ conversion (see below) is required to convert any of the arguments, the program is ill-formed. -\enterexample +\begin{example} \begin{codeblock} struct S { S(std::initializer_list); // \#1 @@ -3714,18 +3714,18 @@ S s2 = { 1, 2, 3 }; // invoke \#2 S s3 = { }; // invoke \#3 \end{codeblock} -\exitexample +\end{example} -\enterexample +\begin{example} \begin{codeblock} struct Map { Map(std::initializer_list>); }; Map ship = {{"Sophie",14}, {"Surprise",28}}; \end{codeblock} -\exitexample +\end{example} -\enterexample +\begin{example} \begin{codeblock} struct S { // no initializer-list constructors @@ -3737,7 +3737,7 @@ S s2 { 1.0, 2, 3 }; // error: narrowing S s3 { }; // OK: invoke \#2 \end{codeblock} -\exitexample +\end{example} \item Otherwise, if the initializer list has a single element of type \tcode{E} and either @@ -3748,21 +3748,21 @@ if a narrowing conversion (see below) is required to convert the element to \tcode{T}, the program is ill-formed. -\enterexample +\begin{example} \begin{codeblock} int x1 {2}; // OK int x2 {2.0}; // error: narrowing \end{codeblock} -\exitexample +\end{example} \item Otherwise, if \tcode{T} is a reference type, a prvalue temporary of the type referenced by \tcode{T} is copy-list-initialized or direct-list-initialized, depending on the kind of initialization for the reference, and the reference is bound to that temporary. -\enternote As usual, the binding will fail and the program is ill-formed if -the reference type is an lvalue reference to a non-const type. \exitnote +\begin{note} As usual, the binding will fail and the program is ill-formed if +the reference type is an lvalue reference to a non-const type. \end{note} -\enterexample +\begin{example} \begin{codeblock} struct S { S(std::initializer_list); // \#1 @@ -3776,7 +3776,7 @@ const int& i2 = { 1.1 }; // error: narrowing const int (&iar)[2] = { 1, 2 }; // OK: \tcode{iar} is bound to temporary array \end{codeblock} -\exitexample +\end{example} \item Otherwise, if \tcode{T} is an enumeration with a fixed underlying type~(\ref{dcl.enum}), @@ -3786,7 +3786,7 @@ if a narrowing conversion is required to convert \tcode{v} to the underlying type of \tcode{T}, the program is ill-formed. -\enterexample +\begin{example} \begin{codeblock} enum byte : unsigned char { }; byte b { 42 }; // OK @@ -3804,20 +3804,20 @@ enum class Handle : uint32_t { Invalid = 0 }; Handle h { 42 }; // OK \end{codeblock} -\exitexample +\end{example} \item Otherwise, if the initializer list has no elements, the object is value-initialized. -\enterexample +\begin{example} \begin{codeblock} int** pp {}; // initialized to null pointer \end{codeblock} -\exitexample +\end{example} \item Otherwise, the program is ill-formed. -\enterexample +\begin{example} \begin{codeblock} struct A { int i; int j; }; A a1 { 1, 2 }; // aggregate initialization @@ -3836,7 +3836,7 @@ int j { 1 }; // initialize to 1 int k { }; // initialize to 0 \end{codeblock} -\exitexample +\end{example} \end{itemize} @@ -3848,11 +3848,11 @@ given \grammarterm{initializer-clause} is sequenced before every value computation and side effect associated with any \grammarterm{initializer-clause} that follows it in the comma-separated list of the \grammarterm{initializer-list}. -\enternote This evaluation ordering holds regardless of the semantics of the +\begin{note} This evaluation ordering holds regardless of the semantics of the initialization; for example, it applies when the elements of the \grammarterm{initializer-list} are interpreted as arguments of a constructor call, even though ordinarily there are no sequencing constraints on the -arguments of a call. \exitnote +arguments of a call. \end{note} \pnum An object of type \tcode{std::initializer_list} is constructed from @@ -3861,10 +3861,10 @@ initializer list. Each element of that array is copy-initialized with the corresponding element of the initializer list, and the \tcode{std::initializer_list} object is constructed to refer to that array. -\enternote A constructor or conversion function selected for the copy shall be +\begin{note} A constructor or conversion function selected for the copy shall be accessible (Clause~\ref{class.access}) in the context of the initializer list. -\exitnote -If a narrowing conversion is required to initialize any of the elements, the program is ill-formed.\enterexample +\end{note} +If a narrowing conversion is required to initialize any of the elements, the program is ill-formed.\begin{example} \begin{codeblock} struct X { X(std::initializer_list v); @@ -3879,14 +3879,14 @@ X x(std::initializer_list(__a, __a+3)); \end{codeblock} -assuming that the implementation can construct an \tcode{initializer_list} object with a pair of pointers. \exitexample +assuming that the implementation can construct an \tcode{initializer_list} object with a pair of pointers. \end{example} \pnum The array has the same lifetime as any other temporary object~(\ref{class.temporary}), except that initializing an \tcode{initializer_list} object from the array extends the lifetime of the array exactly like binding a reference to a temporary. -\enterexample +\begin{example} \begin{codeblock} typedef std::complex cmplx; @@ -3912,9 +3912,9 @@ the constructor's \grammarterm{ctor-initializer} as if by binding a temporary array to a reference member, so the program is ill-formed~(\ref{class.base.init}). -\exitexample -\enternote -The implementation is free to allocate the array in read-only memory if an explicit array with the same initializer could be so allocated. \exitnote +\end{example} +\begin{note} +The implementation is free to allocate the array in read-only memory if an explicit array with the same initializer could be so allocated. \end{note} \pnum A @@ -3941,8 +3941,8 @@ expression whose value after integral promotions will fit into the target type. \end{itemize} -\enternote As indicated above, such conversions are not allowed at the top level in -list-initializations.\exitnote \enterexample +\begin{note} As indicated above, such conversions are not allowed at the top level in +list-initializations.\end{note} \begin{example} \begin{codeblock} int x = 999; // x is not a constant expression @@ -3964,7 +3964,7 @@ int a[] = { 2, f(2), f(2.0) }; // OK: the double-to-int conversion is not at the top level \end{codeblock} -\exitexample% +\end{example}% \indextext{initialization!list-initialization|)}% \indextext{initialization|)}% \indextext{declarator|)} diff --git a/source/derived.tex b/source/derived.tex index e31be64f7e..89631887a7 100644 --- a/source/derived.tex +++ b/source/derived.tex @@ -78,10 +78,10 @@ class but not a direct base class. A class is said to be (directly or indirectly) \term{derived} from its (direct or indirect) base classes. -\enternote +\begin{note} See Clause~\ref{class.access} for the meaning of \grammarterm{access-specifier}. -\exitnote +\end{note} \indextext{access control!base~class member}% Unless redeclared in the derived class, members of a base class are also considered to be members of the derived class. @@ -94,7 +94,7 @@ expressions in the same manner as other members of the derived class, unless their names are hidden or ambiguous~(\ref{class.member.lookup}). \indextext{operator!scope~resolution}% -\enternote +\begin{note} The scope resolution operator \tcode{::}~(\ref{expr.prim}) can be used to refer to a direct or indirect base member explicitly. This allows access to a name that has been redeclared in the derived class. A @@ -104,13 +104,13 @@ class~(\ref{conv.ptr}). An lvalue of a derived class type can be bound to a reference to an accessible unambiguous base class~(\ref{dcl.init.ref}). -\exitnote +\end{note} \pnum The \grammarterm{base-specifier-list} specifies the type of the \term{base class subobjects} contained in an object of the derived class type. -\enterexample +\begin{example} \indextext{example!derived~class}% \begin{codeblock} struct Base { @@ -133,7 +133,7 @@ Here, an object of class \tcode{Derived2} will have a subobject of class \tcode{Derived} which in turn will have a subobject of class \tcode{Base}. -\exitexample +\end{example} \pnum A \grammarterm{base-specifier} followed by an ellipsis is a pack @@ -142,7 +142,7 @@ \pnum The order in which the base class subobjects are allocated in the most derived object~(\ref{intro.object}) is unspecified. -\enternote +\begin{note} \indextext{directed~acyclic~graph|see{DAG}}% \indextext{lattice|see{DAG, subobject}}% a derived class and its base class subobjects can be represented by a @@ -158,16 +158,16 @@ \pnum The arrows need not have a physical representation in memory. -\exitnote +\end{note} \pnum -\enternote +\begin{note} Initialization of objects representing base classes can be specified in constructors; see~\ref{class.base.init}. -\exitnote +\end{note} \pnum -\enternote +\begin{note} A base class subobject might have a layout~(\ref{basic.stc}) different from the layout of a most derived object of the same type. A base class subobject might have a polymorphic behavior~(\ref{class.cdtor}) @@ -176,7 +176,7 @@ however, two subobjects that have the same class type and that belong to the same most derived object must not be allocated at the same address~(\ref{expr.eq}). -\exitnote +\end{note} \rSec1[class.mi]{Multiple base classes} \indextext{multiple~inheritance}% @@ -184,40 +184,40 @@ \pnum A class can be derived from any number of base classes. -\enternote +\begin{note} The use of more than one direct base class is often called multiple inheritance. -\exitnote -\enterexample +\end{note} +\begin{example} \begin{codeblock} class A { /* ... */ }; class B { /* ... */ }; class C { /* ... */ }; class D : public A, public B, public C { /* ... */ }; \end{codeblock} -\exitexample +\end{example} \pnum \indextext{layout!class~object}% \indextext{initialization!order~of}% -\enternote +\begin{note} The order of derivation is not significant except as specified by the semantics of initialization by constructor~(\ref{class.base.init}), cleanup~(\ref{class.dtor}), and storage layout~(\ref{class.mem},~\ref{class.access.spec}). -\exitnote +\end{note} \pnum A class shall not be specified as a direct base class of a derived class more than once. -\enternote +\begin{note} A class can be an indirect base class more than once and can be a direct and an indirect base class. There are limited things that can be done with such a class. The non-static data members and member functions of the direct base class cannot be referred to in the scope of the derived class. However, the static members, enumerations and types can be unambiguously referred to. -\exitnote -\enterexample +\end{note} +\begin{example} \begin{codeblock} class X { /* ... */ }; class Y : public X, public X { /* ... */ }; // ill-formed @@ -230,7 +230,7 @@ class C : public A, public B { void f(); /* ... */ }; // well-formed class D : public A, public L { void f(); /* ... */ }; // well-formed \end{codeblock} -\exitexample +\end{example} \pnum \indextext{virtual~base~class}% @@ -243,7 +243,7 @@ corresponding distinct base class subobject of that type. For each distinct base class that is specified virtual, the most derived object shall contain a single base class subobject of that type. -\enterexample +\begin{example} for an object of class type \tcode{C}, each distinct occurrence of a (non-virtual) base class \tcode{L} in the class lattice of \tcode{C} corresponds one-to-one with a distinct \tcode{L} subobject within the @@ -320,7 +320,7 @@ {figvirtnonvirt.pdf} \end{importgraphic} -\exitexample +\end{example} \rSec1[class.member.lookup]{Member name lookup}% \indextext{lookup!member name}% @@ -358,7 +358,7 @@ declaration set contains every declaration of \tcode{f} declared in \tcode{C} that satisfies the requirements of the language construct in which the lookup occurs. -\enternote +\begin{note} Looking up a name in an \grammarterm{elaborated-type-specifier}~(\ref{basic.lookup.elab}) or \grammarterm{base-specifier} (Clause~\ref{class.derived}), for instance, @@ -369,7 +369,7 @@ \grammarterm{using-declaration}~(\ref{namespace.udecl}) includes the declaration of a class or enumeration that would ordinarily be hidden by another declaration of that name in the same scope. -\exitnote +\end{note} If the resulting declaration set is not empty, the subobject set contains \tcode{C} itself, and calculation is complete. @@ -405,7 +405,7 @@ \pnum The result of name lookup for \tcode{f} in \tcode{C} is the declaration set of $S(f,C)$. If it is an invalid set, the program is ill-formed. -\enterexample +\begin{example} \begin{codeblock} struct A { int x; }; // S(x,A) = \{ \{ \tcode{A::x} \}, \{ \tcode{A} \} \} struct B { float x; }; // S(x,B) = \{ \{ \tcode{B::x} \}, \{ \tcode{B} \} \} @@ -422,7 +422,7 @@ $S(x,F)$ is unambiguous because the \tcode{A} and \tcode{B} base subobjects of \tcode{D} are also base subobjects of \tcode{E}, so $S(x,D)$ is discarded in the first merge step. -\exitexample +\end{example} \pnum \indextext{access~control!overloading~resolution~and}% @@ -433,7 +433,7 @@ \indextext{example!explicit~qualification}% \indextext{overloading!resolution!scoping ambiguity}% Ambiguities can often be resolved by qualifying a name with its class name. -\enterexample +\begin{example} \begin{codeblock} struct A { int f(); @@ -451,16 +451,16 @@ int f() { return A::f() + B::f(); } }; \end{codeblock} -\exitexample +\end{example} \pnum -\enternote +\begin{note} A static member, a nested type or an enumerator defined in a base class \tcode{T} can unambiguously be found even if an object has more than one base class subobject of type \tcode{T}. Two base class subobjects share the non-static member subobjects of their common virtual base classes. -\exitnote -\enterexample +\end{note} +\begin{example} \begin{codeblock} struct V { int v; @@ -481,18 +481,18 @@ pd->a++; // error, ambiguous: two \tcode{a}{s} in \tcode{D} } \end{codeblock} -\exitexample +\end{example} \pnum -\enternote +\begin{note} \indextext{dominance!virtual~base~class}% When virtual base classes are used, a hidden declaration can be reached along a path through the subobject lattice that does not pass through the hiding declaration. This is not an ambiguity. The identical use with non-virtual base classes is an ambiguity; in that case there is no unique instance of the name that hides all the others. -\exitnote -\enterexample +\end{note} +\begin{example} \begin{codeblock} struct V { int f(); int x; }; struct W { int g(); int y; }; @@ -512,11 +512,11 @@ \end{importgraphic} \pnum -\enternote +\begin{note} The names declared in \tcode{V} and the left-hand instance of \tcode{W} are hidden by those in \tcode{B}, but the names declared in the right-hand instance of \tcode{W} are not hidden at all. -\exitnote +\end{note} \begin{codeblock} void D::glorp() { x++; // OK: \tcode{B::x} hides \tcode{V::x} @@ -525,7 +525,7 @@ g(); // error: \tcode{B::g()} and \tcode{C}'s \tcode{W::g()} } \end{codeblock} -\exitexample +\end{example} \indextext{ambiguity!class conversion}% \pnum @@ -534,7 +534,7 @@ of a derived class to a pointer or reference to one of its base classes shall unambiguously refer to a unique object representing the base class. -\enterexample +\begin{example} \begin{codeblock} struct V { }; struct A { }; @@ -549,14 +549,14 @@ V* pv = &d; // OK: only one \tcode{V} subobject } \end{codeblock} -\exitexample +\end{example} \pnum -\enternote +\begin{note} Even if the result of name lookup is unambiguous, use of a name found in multiple subobjects might still be -ambiguous~(\ref{conv.mem},~\ref{expr.ref}, \ref{class.access.base}).\exitnote -\enterexample +ambiguous~(\ref{conv.mem},~\ref{expr.ref}, \ref{class.access.base}).\end{note} +\begin{example} \begin{codeblock} struct B1 { void f(); @@ -580,7 +580,7 @@ int D::* mpD = &D::i; // Ambiguous conversion } }; -\end{codeblock}\exitexample +\end{codeblock}\end{example} \rSec1[class.virtual]{Virtual functions}% \indextext{virtual~function|(}% @@ -613,7 +613,7 @@ base class subobject (if any) declares or inherits another member function that overrides \tcode{vf}. In a derived class, if a virtual member function of a base class subobject has more than one final overrider the program is ill-formed. -\enterexample +\begin{example} \begin{codeblock} struct A { virtual void f(); @@ -631,9 +631,9 @@ c.C::f(); // calls \tcode{A::f} because of the using-declaration } \end{codeblock} -\exitexample +\end{example} -\enterexample +\begin{example} \begin{codeblock} struct A { virtual void f(); }; struct B : A { }; @@ -641,10 +641,10 @@ struct D : B, C { }; // OK: \tcode{A::f} and \tcode{C::f} are the final overriders // for the \tcode{B} and \tcode{C} subobjects, respectively \end{codeblock} -\exitexample +\end{example} \pnum -\enternote +\begin{note} A virtual member function does not have to be visible to be overridden, for example, \begin{codeblock} @@ -665,12 +665,12 @@ \tcode{B::f()}, and therefore is a virtual function that overrides the function \tcode{B::f()} even though \tcode{B::f()} is not visible in class \tcode{D2}. -\exitnote +\end{note} \pnum If a virtual function \tcode{f} in some class \tcode{B} is marked with the \grammarterm{virt-specifier} \tcode{final} and in a class \tcode{D} derived from \tcode{B} -a function \tcode{D::f} overrides \tcode{B::f}, the program is ill-formed. \enterexample +a function \tcode{D::f} overrides \tcode{B::f}, the program is ill-formed. \begin{example} \begin{codeblock} struct B { virtual void f() const final; @@ -680,11 +680,11 @@ void f() const; // error: \tcode{D::f} attempts to override \tcode{final} \tcode{B::f} }; \end{codeblock} -\exitexample +\end{example} \pnum If a virtual function is marked with the \grammarterm{virt-specifier} \tcode{override} and -does not override a member function of a base class, the program is ill-formed. \enterexample +does not override a member function of a base class, the program is ill-formed. \begin{example} \begin{codeblock} struct B { virtual void f(int); @@ -695,7 +695,7 @@ virtual void f(int) override; // OK }; \end{codeblock} -\exitexample +\end{example} \pnum Even though destructors are not inherited, a destructor in a derived @@ -733,7 +733,7 @@ final overrider of the overridden function, its result is converted to the type returned by the (statically chosen) overridden function~(\ref{expr.call}). -\enterexample +\begin{example} \indextext{example!virtual~function}% \begin{codeblock} class B { }; @@ -776,26 +776,26 @@ dp->vf2(); // ill-formed: argument mismatch } \end{codeblock} -\exitexample +\end{example} \pnum -\enternote +\begin{note} The interpretation of the call of a virtual function depends on the type of the object for which it is called (the dynamic type), whereas the interpretation of a call of a non-virtual member function depends only on the type of the pointer or reference denoting that object (the static type)~(\ref{expr.call}). -\exitnote +\end{note} \pnum -\enternote +\begin{note} The \tcode{virtual} specifier implies membership, so a virtual function cannot be a nonmember~(\ref{dcl.fct.spec}) function. Nor can a virtual function be a static member, since a virtual function call relies on a specific object for determining which function to invoke. A virtual function declared in one class can be declared a \tcode{friend} in another class. -\exitnote +\end{note} \pnum \indextext{definition!virtual~function}% @@ -806,7 +806,7 @@ \pnum \indextext{multiple~inheritance!\tcode{virtual}~and}% -\enterexample +\begin{example} here are some uses of virtual functions with multiple base classes: \indextext{example!virtual~function}% \begin{codeblock} @@ -882,14 +882,14 @@ vb1ap->f(); // calls \tcode{VB2::f} } \end{codeblock} -\exitexample +\end{example} \pnum \indextext{operator!scope~resolution}% \indextext{virtual~function~call}% Explicit qualification with the scope operator~(\ref{expr.prim}) suppresses the virtual call mechanism. -\enterexample +\begin{example} \begin{codeblock} class B { public: virtual void f(); }; class D : public B { public: void f(); }; @@ -903,7 +903,7 @@ \tcode{B::f} and not \tcode{D::f}. -\exitexample +\end{example} \pnum A function with a deleted definition~(\ref{dcl.fct.def}) shall @@ -927,9 +927,9 @@ as a base class of some other class; no objects of an abstract class can be created except as subobjects of a class derived from it. A class is abstract if it has at least one \term{pure virtual function}. -\enternote +\begin{note} Such a function might be inherited: see below. -\exitnote +\end{note} \indextext{virtual~function!pure}% A virtual function is specified \term{pure} by using a \grammarterm{pure-specifier}~(\ref{class.mem}) in the function declaration @@ -938,7 +938,7 @@ A pure virtual function need be defined only if called with, or as if with~(\ref{class.dtor}), the \grammarterm{qualified-id} syntax~(\ref{expr.prim}). -\enterexample +\begin{example} \indextext{example!pure virtual~function}% \begin{codeblock} class point { /* ... */ }; @@ -951,25 +951,25 @@ virtual void draw() = 0; // pure virtual }; \end{codeblock} -\exitexample -\enternote +\end{example} +\begin{note} A function declaration cannot provide both a \grammarterm{pure-specifier} and a definition -\exitnote -\enterexample +\end{note} +\begin{example} \begin{codeblock} struct C { virtual void f() = 0 { }; // ill-formed }; \end{codeblock} -\exitexample +\end{example} \pnum \indextext{class!pointer~to abstract}% An abstract class shall not be used as a parameter type, as a function return type, or as the type of an explicit conversion. Pointers and references to an abstract class can be declared. -\enterexample +\begin{example} \begin{codeblock} shape x; // error: object of abstract class shape* p; // OK @@ -977,13 +977,13 @@ void g(shape); // error shape& h(shape&); // OK \end{codeblock} -\exitexample +\end{example} \pnum \indextext{virtual~function!pure}% A class is abstract if it contains or inherits at least one pure virtual function for which the final overrider is pure virtual. -\enterexample +\begin{example} \begin{codeblock} class ab_circle : public shape { int radius; @@ -1006,14 +1006,14 @@ \end{codeblock} would make class \tcode{circle} nonabstract and a definition of \tcode{circle::draw()} must be provided. -\exitexample +\end{example} \pnum -\enternote +\begin{note} An abstract class can be derived from a class that is not abstract, and a pure virtual function may override a virtual function which is not pure. -\exitnote +\end{note} \pnum \indextext{class!constructor~and abstract}% diff --git a/source/diagnostics.tex b/source/diagnostics.tex index eea61d0877..c532c12681 100644 --- a/source/diagnostics.tex +++ b/source/diagnostics.tex @@ -569,7 +569,7 @@ \rSec1[errno]{Error numbers} \pnum -The header \tcode{} is described in Table~\ref{tab:diagnostics.hdr.cerrno}. Its contents are the same as the POSIX header \tcode{}, except that \tcode{errno} shall be defined as a macro. \enternote The intent is to remain in close alignment with the POSIX standard. \exitnote A separate \tcode{errno} value shall be provided for each thread. +The header \tcode{} is described in Table~\ref{tab:diagnostics.hdr.cerrno}. Its contents are the same as the POSIX header \tcode{}, except that \tcode{errno} shall be defined as a macro. \begin{note} The intent is to remain in close alignment with the POSIX standard. \end{note} A separate \tcode{errno} value shall be provided for each thread. \begin{libsyntab6}{cerrno}{tab:diagnostics.hdr.cerrno} @@ -839,11 +839,11 @@ categories of errors in addition to those defined in this International Standard. Such classes shall behave as specified in this -subclause. \enternote \tcode{error_category} objects are +subclause. \begin{note} \tcode{error_category} objects are passed by reference, and two such objects are equal if they have the same address. This means that applications using custom \tcode{error_category} types should create a single object of each -such type. \exitnote +such type. \end{note} \indexlibrary{\idxcode{error_category}}% \indexlibrary{\idxcode{generic_category}}% @@ -985,7 +985,7 @@ \pnum \returns \tcode{less()(this, \&rhs)}. -\enternote \tcode{less}~(\ref{comparisons}) provides a total ordering for pointers. \exitnote +\begin{note} \tcode{less}~(\ref{comparisons}) provides a total ordering for pointers. \end{note} \end{itemdescr} \rSec3[syserr.errcat.derived]{Program defined classes derived from \tcode{error_category}} @@ -1070,9 +1070,9 @@ function shall return \tcode{error_condition(posv, generic_category())}. Otherwise, the function shall return \tcode{error_condition(ev, system_category())}. What constitutes correspondence for any given operating -system is unspecified. \enternote The number of potential system error codes is large +system is unspecified. \begin{note} The number of potential system error codes is large and unbounded, and some may not correspond to any POSIX \tcode{errno} value. Thus -implementations are given latitude in determining correspondence. \exitnote +implementations are given latitude in determining correspondence. \end{note} \end{itemdescr} \rSec2[syserr.errcode]{Class \tcode{error_code}} @@ -1082,8 +1082,8 @@ \pnum The class \tcode{error_code} describes an object used to hold error code values, such as those originating from the operating system or other low-level -application program interfaces. \enternote Class \tcode{error_code} is an -adjunct to error reporting by exception. \exitnote +application program interfaces. \begin{note} Class \tcode{error_code} is an +adjunct to error reporting by exception. \end{note} \indexlibrary{\idxcode{error_code}}% \begin{codeblock} @@ -1317,8 +1317,8 @@ \pnum The class \tcode{error_condition} describes an object used to hold values identifying -error conditions. \enternote \tcode{error_condition} values are portable abstractions, -while \tcode{error_code} values~(\ref{syserr.errcode}) are implementation specific. \exitnote +error conditions. \begin{note} \tcode{error_condition} values are portable abstractions, +while \tcode{error_code} values~(\ref{syserr.errcode}) are implementation specific. \end{note} \indexlibrary{\idxcode{error_code}}% \begin{codeblock} @@ -1601,9 +1601,9 @@ application program interfaces. \pnum -\enternote If an error represents an out-of-memory condition, implementations are +\begin{note} If an error represents an out-of-memory condition, implementations are encouraged to throw an exception object of type \tcode{bad_alloc}~\ref{bad.alloc} rather -than \tcode{system_error}. \exitnote +than \tcode{system_error}. \end{note} \indexlibrary{\idxcode{system_error}}% \begin{codeblock} @@ -1742,6 +1742,6 @@ \pnum \returns An \ntbs incorporating the arguments supplied in the constructor. -\enternote The returned NTBS might be the contents of \tcode{what_arg + ": " + -code.message()}.\exitnote +\begin{note} The returned NTBS might be the contents of \tcode{what_arg + ": " + +code.message()}.\end{note} \end{itemdescr} diff --git a/source/exceptions.tex b/source/exceptions.tex index fd0014c32c..811c75f107 100644 --- a/source/exceptions.tex +++ b/source/exceptions.tex @@ -58,9 +58,9 @@ \indextext{try block|see{exception handling, try block}}% \indextext{handler|see{exception handling, handler}}% A \grammarterm{try-block} is a \grammarterm{statement} (Clause~\ref{stmt.stmt}). -\enternote Within this Clause +\begin{note} Within this Clause ``try block'' is taken to mean both \grammarterm{try-block} and -\grammarterm{function-try-block}. \exitnote +\grammarterm{function-try-block}. \end{note} \pnum \indextext{exception handling!\idxcode{goto}}% @@ -71,7 +71,7 @@ \indextext{\idxcode{switch}!and handler}% A \tcode{goto} or \tcode{switch} statement shall not be used to transfer control into a try block or into a handler. -\enterexample +\begin{example} \begin{codeblock} void f() { goto l1; // Ill-formed @@ -88,7 +88,7 @@ } \end{codeblock} -\exitexample +\end{example} \indextext{\idxcode{goto}!and try block}% \indextext{\idxcode{switch}!and try block}% \indextext{\idxcode{return}!and try block}% @@ -108,7 +108,7 @@ When this happens, each variable declared in the try block will be destroyed in the context that directly contains its declaration. -\enterexample +\begin{example} \begin{codeblock} lab: try { @@ -138,7 +138,7 @@ \tcode{t1} will result in executing \textit{handler 1}. -\exitexample +\end{example} \pnum \indextext{function try block|see{exception handling, function try block}}% @@ -161,7 +161,7 @@ in the same way as an exception thrown during the execution of a \grammarterm{try-block} transfers control to other handlers. -\enterexample +\begin{example} \begin{codeblock} int f(int); class C { @@ -181,7 +181,7 @@ } \end{codeblock} -\exitexample +\end{example} \pnum In this section, ``before'' and ``after'' refer to the @@ -193,7 +193,7 @@ \pnum Throwing an exception transfers control to a handler. -\enternote +\begin{note} An exception can be thrown from one of the following contexts: \grammarterm{throw-expression}{s}~(\ref{expr.throw}), allocation functions~(\ref{basic.stc.dynamic.allocation}), @@ -201,10 +201,10 @@ \tcode{typeid}~(\ref{expr.typeid}), \grammarterm{new-expression}{s}~(\ref{expr.new}), and standard library functions~(\ref{structure.specifications}). -\exitnote +\end{note} An object is passed and the type of that object determines which handlers can catch it. -\enterexample +\begin{example} \begin{codeblock} throw "Help!"; \end{codeblock} @@ -242,7 +242,7 @@ // handle exceptions of type \tcode{Overflow} here } \end{codeblock} -\exitexample +\end{example} \pnum \indextext{exception handling!throwing}% @@ -290,9 +290,9 @@ The implementation may then deallocate the memory for the exception object; any such deallocation is done in an unspecified way. -\enternote a thrown exception does not +\begin{note} a thrown exception does not propagate to other threads unless caught, stored, and rethrown using -appropriate library functions; see~\ref{propagation} and~\ref{futures}. \exitnote +appropriate library functions; see~\ref{propagation} and~\ref{futures}. \end{note} \pnum \indextext{exception handling!exception object!constructor}% @@ -310,10 +310,10 @@ \indextext{reraise|see{exception handling, rethrow}}% An exception is considered caught when a handler for that exception becomes active~(\ref{except.handle}). -\enternote +\begin{note} An exception can have active handlers and still be considered uncaught if it is rethrown. -\exitnote +\end{note} \pnum \indextext{exception handling!terminate called@\tcode{terminate()} called}% @@ -321,7 +321,7 @@ If the exception handling mechanism, after completing the initialization of the exception object but before the activation of a handler for the exception, calls a function that exits via an -exception, \tcode{std::terminate} is called~(\ref{except.terminate}). \enterexample +exception, \tcode{std::terminate} is called~(\ref{except.terminate}). \begin{example} \begin{codeblock} struct C { @@ -341,7 +341,7 @@ } \end{codeblock} -\exitexample +\end{example} \rSec1[except.ctor]{Constructors and destructors}% @@ -356,10 +356,10 @@ destructors are invoked by a process, specified in this section, called \defn{stack unwinding}. If a destructor directly invoked by stack unwinding exits with an exception, \tcode{std::terminate} is called~(\ref{except.terminate}). -\enternote +\begin{note} Consequently, destructors should generally catch exceptions and not let them propagate out of the destructor. -\exitnote +\end{note} \pnum The destructor is invoked for each automatic object of class type constructed, @@ -370,7 +370,7 @@ the destructor for the returned object (if any) is also invoked. The objects are destroyed in the reverse order of the completion of their construction. -\enterexample +\begin{example} \begin{codeblock} struct A { }; @@ -394,7 +394,7 @@ resulting in the destruction of the returned object, followed by the destruction of the local variable \tcode{a}. Finally, the returned object is constructed again at \#2. -\exitexample +\end{example} \pnum For an object of class type @@ -419,11 +419,11 @@ \grammarterm{function-try-block} of a delegating constructor for that object, if any. \pnum -\enternote +\begin{note} If the object was allocated by a \grammarterm{new-expression}~(\ref{expr.new}), the matching deallocation function~(\ref{basic.stc.dynamic.deallocation}), if any, is called to free the storage occupied by the object. -\exitnote +\end{note} \rSec1[except.handle]{Handling an exception} @@ -509,14 +509,14 @@ \end{itemize} -\enternote +\begin{note} A \grammarterm{throw-expression} whose operand is an integer literal with value zero does not match a handler of pointer or pointer to member type. -\exitnote +\end{note} -\enterexample +\begin{example} \begin{codeblock} class Matherr { /* ... */ virtual void vf(); }; class Overflow: public Matherr { /* ... */ }; @@ -547,7 +547,7 @@ \tcode{Underflow} and \tcode{Zerodivide}. -\exitexample +\end{example} \pnum The handlers for a try block are tried in order of appearance. @@ -577,9 +577,9 @@ \pnum A handler is considered active when initialization is complete for the parameter (if any) of the catch clause. -\enternote +\begin{note} The stack will have been unwound at that point. -\exitnote +\end{note} Also, an implicit handler is considered active when \tcode{std::terminate()} or @@ -808,7 +808,7 @@ exception specification of the base class virtual function, unless the overriding function is defined as deleted. -\enterexample +\begin{example} \begin{codeblock} struct B { virtual void f() throw (int, double); @@ -829,7 +829,7 @@ \tcode{int} and \tcode{double}. -\exitexample +\end{example} \pnum An @@ -837,11 +837,11 @@ can include the same type more than once and can include classes that are related by inheritance, even though doing so is redundant. -\enternote An +\begin{note} An \grammarterm{exception-specification} can also include the class \tcode{std::bad_exception}~(\ref{bad.exception}). -\exitnote +\end{note} \pnum \indextext{allowing an exception|see{exception specification, allowing an exception}}% @@ -880,7 +880,7 @@ \item otherwise, the function \tcode{std::terminate()} is called~(\ref{except.terminate}). \end{itemize} -\enterexample +\begin{example} \begin{codeblock} class X { }; class Y { }; @@ -894,17 +894,17 @@ throw W(); // will call \tcode{std::unexpected()} } \end{codeblock} -\exitexample +\end{example} -\enternote A function can have multiple declarations with different non-throwing +\begin{note} A function can have multiple declarations with different non-throwing \grammarterm{exception-specification}{s}; for this purpose, the one on the -function definition is used. \exitnote +function definition is used. \end{note} \pnum An implementation shall not reject an expression merely because when executed it throws or might throw an exception that the containing function does not allow. -\enterexample +\begin{example} \begin{codeblock} extern void f() throw(X, Y); @@ -922,15 +922,15 @@ that \tcode{g} does not allow. -\exitexample +\end{example} \pnum -\enternote +\begin{note} An exception specification is not considered part of a function's type; see~\ref{dcl.fct}. -\exitnote +\end{note} \pnum The \defn{set of potential exceptions} of a given context is @@ -1011,7 +1011,7 @@ \placeholder{S} consists of the type \tcode{std::bad_typeid}. \end{itemize} -\enterexample +\begin{example} Given the following declarations \begin{codeblock} void f() throw(int); @@ -1033,7 +1033,7 @@ \item for \tcode{new D}, the set is the set of all types. \end{itemize} -\exitexample +\end{example} \pnum A function with an implied non-throwing exception specification, @@ -1062,14 +1062,14 @@ \end{itemize} (including default argument expressions used in such invocations) as selected by overload resolution for the implicit definition of \tcode{f} (\ref{class.ctor}). -\enternote +\begin{note} Even though destructors for fully-constructed subobjects are invoked when an exception is thrown during the execution of a constructor (\ref{except.ctor}), their exception specifications do not contribute to the exception specification of the constructor, because an exception thrown from such a destructor could never escape the constructor (\ref{except.throw}, \ref{except.terminate}). -\exitnote +\end{note} \item the sets of potential exceptions of the initialization of non-static data members from \grammarterm{brace-or-equal-initializer}{s} that are not ignored (\ref{class.base.init}); @@ -1088,7 +1088,7 @@ and for \tcode{X}'s virtual and direct base classes. \end{itemize} -\enterexample +\begin{example} \begin{codeblock} struct A { A(int = (A(5), 0)) noexcept; @@ -1129,7 +1129,7 @@ and the program would be ill-formed since a function that overrides a virtual function from a base class shall have an \grammarterm{exception-specification} at least as restrictive as that in the base class. -\exitexample +\end{example} \pnum A deallocation function~(\ref{basic.stc.dynamic.deallocation}) @@ -1155,12 +1155,12 @@ \item the \grammarterm{exception-specification} is needed for a defaulted special member function that calls the function. -\enternote A defaulted declaration does not require the +\begin{note} A defaulted declaration does not require the \grammarterm{exception-specification} of a base member function to be evaluated until the implicit \grammarterm{exception-specification} of the derived function is needed, but an explicit \grammarterm{exception-specification} needs the implicit \grammarterm{exception-specification} to compare against. -\exitnote +\end{note} \end{itemize} The \grammarterm{exception-specification} of a defaulted special member @@ -1177,8 +1177,8 @@ pack expansion~(\ref{temp.variadic}). \pnum -\enternote The use of \grammarterm{dynamic-exception-specification}{s} is deprecated -(see Annex~\ref{depr}). \exitnote% +\begin{note} The use of \grammarterm{dynamic-exception-specification}{s} is deprecated +(see Annex~\ref{depr}). \end{note}% \indextext{exception specification|)} \rSec1[except.special]{Special functions} @@ -1197,7 +1197,7 @@ \pnum \indextext{\idxcode{terminate()}}% In some situations exception handling must be abandoned -for less subtle error handling techniques. \enternote These situations are: +for less subtle error handling techniques. \begin{note} These situations are: \indextext{\idxcode{terminate()}!called}% \begin{itemize} @@ -1277,7 +1277,7 @@ \end{itemize} -\exitnote +\end{note} \pnum \indextext{\idxcode{terminate()}}% @@ -1320,9 +1320,9 @@ the stack unwinding for the former function. \pnum -\enternote By default, \tcode{std::unexpected()} calls \tcode{std::terminate()}, but a +\begin{note} By default, \tcode{std::unexpected()} calls \tcode{std::terminate()}, but a program can install its own handler function~(\ref{set.unexpected}). In either case, the -constraints in the following paragraph apply. \exitnote +constraints in the following paragraph apply. \end{note} \pnum The @@ -1351,7 +1351,7 @@ was violated. \pnum -\enternote +\begin{note} Thus, a \grammarterm{dynamic-exception-specification} guarantees that a function exits only via an exception of one of the listed types. @@ -1363,7 +1363,7 @@ \tcode{std\-::\-bad_ex\-cep\-tion} within the function \tcode{std::unexpected()}. -\exitnote +\end{note} \rSec2[except.uncaught]{The \tcode{std::uncaught_exceptions()} function}% \indexlibrary{\idxcode{uncaught_exceptions}} diff --git a/source/expressions.tex b/source/expressions.tex index a2d36526ab..11fe1c3be0 100644 --- a/source/expressions.tex +++ b/source/expressions.tex @@ -16,18 +16,18 @@ \pnum \indextext{expression|(}% -\enternote +\begin{note} Clause~\ref{expr} defines the syntax, order of evaluation, and meaning of expressions.\footnote{The precedence of operators is not directly specified, but it can be derived from the syntax.} An expression is a sequence of operators and operands that specifies a computation. An expression can result in a value and can cause side effects. -\exitnote +\end{note} \pnum \indextext{operator!overloaded}% -\enternote +\begin{note} Operators can be overloaded, that is, given meaning when applied to expressions of class type~(Clause \ref{class}) or enumeration type~(\ref{dcl.enum}). Uses of overloaded operators are transformed into @@ -37,7 +37,7 @@ by the rules for function call. Relations between operators, such as \tcode{++a} meaning \tcode{a+=1}, are not guaranteed for overloaded operators~(\ref{over.oper}). -\exitnote +\end{note} \pnum Clause~\ref{expr} defines the effects of operators when applied to types @@ -61,13 +61,13 @@ If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined. -\enternote +\begin{note} \indextext{overflow}% most existing implementations of \Cpp ignore integer overflows. Treatment of division by zero, forming a remainder using a zero divisor, and all floating point exceptions vary among machines, and is usually adjustable by a library function. -\exitnote +\end{note} \pnum \indextext{expression!reference}% @@ -76,10 +76,10 @@ \tcode{T} prior to any further analysis. The expression designates the object or function denoted by the reference, and the expression is an lvalue or an xvalue, depending on the expression. -\enternote +\begin{note} Before the lifetime of the reference has started or after it has ended, the behavior is undefined (see~\ref{basic.life}). -\exitnote +\end{note} \pnum If a prvalue initially has the type ``\cv{} \tcode{T}'', where @@ -88,7 +88,7 @@ \pnum \indextext{expression!rvalue~reference}% -\enternote +\begin{note} An expression is an xvalue if it is: \begin{itemize} \item the result of calling a function, whether implicitly or explicitly, @@ -106,9 +106,9 @@ In general, the effect of this rule is that named rvalue references are treated as lvalues and unnamed rvalue references to objects are treated as xvalues; rvalue references to functions are treated as lvalues whether named or not. -\exitnote +\end{note} -\enterexample +\begin{example} \begin{codeblock} struct A { int m; @@ -122,18 +122,18 @@ The expressions \tcode{f()}, \tcode{f().m}, \tcode{static_cast(a)}, and \tcode{a + a} are xvalues. The expression \tcode{ar} is an lvalue. -\exitexample +\end{example} \pnum In some contexts, \defnx{unevaluated operands}{unevaluated operand} appear~(\ref{expr.typeid}, \ref{expr.sizeof}, \ref{expr.unary.noexcept}, \ref{dcl.type.simple}). An unevaluated operand is not evaluated. An unevaluated operand is considered a full-expression. -\enternote +\begin{note} In an unevaluated operand, a non-static class member may be named~(\ref{expr.prim}) and naming of objects or functions does not, by itself, require that a definition be provided~(\ref{basic.def.odr}). -\exitnote +\end{note} \pnum Whenever a glvalue expression appears as an operand of an operator that @@ -141,12 +141,12 @@ lvalue-to-rvalue~(\ref{conv.lval}), array-to-pointer~(\ref{conv.array}), or function-to-pointer~(\ref{conv.func}) standard conversions are applied to convert the expression to a prvalue. -\enternote +\begin{note} because cv-qualifiers are removed from the type of an expression of non-class type when the expression is converted to a prvalue, an lvalue expression of type \tcode{const int} can, for example, be used where a prvalue expression of type \tcode{int} is required. -\exitnote +\end{note} \pnum \indextext{conversion!usual arithmetic}% @@ -226,11 +226,11 @@ these expressions. \end{itemize} -\enternote Using an overloaded operator causes a function call; the +\begin{note} Using an overloaded operator causes a function call; the above covers only operators with built-in meaning. If the lvalue is of class type, it must have a volatile copy constructor to initialize the temporary that is the result of the lvalue-to-rvalue -conversion. \exitnote +conversion. \end{note} \pnum The values of the floating operands and the results of floating @@ -255,9 +255,9 @@ \tcode{const} is added to every \cv$_{3,k}$ for $0 < k < j$. \end{itemize} -\enternote Given similar types \tcode{T1} and \tcode{T2}, this +\begin{note} Given similar types \tcode{T1} and \tcode{T2}, this construction ensures that -both can be converted to \tcode{T3}. \exitnote +both can be converted to \tcode{T3}. \end{note} \indextext{pointer!composite pointer type}% The \defn{composite pointer type} of two operands \tcode{p1} and @@ -308,7 +308,7 @@ composite pointer type is ill-formed. \end{itemize} -\enterexample +\begin{example} \begin{codeblock} typedef void *p; typedef const int *q; @@ -319,7 +319,7 @@ The composite pointer type of \tcode{p} and \tcode{q} is ``pointer to \tcode{const void}''; the composite pointer type of \tcode{pi} and \tcode{pci} is ``pointer to \tcode{const} pointer to \tcode{const int}''. -\exitexample +\end{example} \rSec1[expr.prim]{Primary expressions}% \indextext{expression!primary|(} @@ -377,13 +377,13 @@ before the optional \grammarterm{cv-qualifier-seq} and it shall not appear within the declaration of a static member function (although its type and value category are defined within a static member function as they are within a non-static -member function). \enternote this is because declaration matching does not -occur until the complete declarator is known. \exitnote Unlike the object +member function). \begin{note} this is because declaration matching does not +occur until the complete declarator is known. \end{note} Unlike the object expression in other contexts, \tcode{*this} is not required to be of complete type for purposes of class member access~(\ref{expr.ref}) outside the member -function body. \enternote only class members declared prior to the declaration -are visible. \exitnote -\enterexample +function body. \begin{note} only class members declared prior to the declaration +are visible. \end{note} +\begin{example} \begin{codeblock} struct A { char g(); @@ -392,7 +392,7 @@ }; template auto A::f(int t) -> decltype(t + g()); \end{codeblock} -\exitexample +\end{example} \pnum Otherwise, if a \grammarterm{member-declarator} declares a non-static data @@ -403,7 +403,7 @@ \pnum The expression \tcode{this} shall not appear in any other context. -\enterexample +\begin{example} \begin{codeblock} class Outer { int a[sizeof(*this)]; // error: not inside a member function @@ -418,7 +418,7 @@ } }; \end{codeblock} -\exitexample +\end{example} \pnum \indextext{expression!parenthesized}% @@ -434,16 +434,16 @@ \indextext{id-expression}% An \grammarterm{id-expression} is a restricted form of a \grammarterm{primary-expression}. -\enternote +\begin{note} an \grammarterm{id-expression} can appear after \tcode{.} and \tcode{->} operators~(\ref{expr.ref}). -\exitnote +\end{note} \pnum \indextext{identifier}% An \grammarterm{identifier} is an \grammarterm{id-expression} provided it has been suitably declared (Clause~\ref{dcl.dcl}). -\enternote +\begin{note} for \grammarterm{operator-function-id}{s}, see~\ref{over.oper}; for \grammarterm{conversion-function-id}{s}, see~\ref{class.conv.fct}; for \grammarterm{literal-operator-id}{s}, see~\ref{over.literal}; for @@ -453,7 +453,7 @@ Within the definition of a non-static member function, an \grammarterm{identifier} that names a non-static member is transformed to a class member access expression~(\ref{class.mfct.non-static}). -\exitnote +\end{note} The type of the expression is the type of the \grammarterm{identifier}. The result is the entity denoted by the identifier. The result is an lvalue if the entity is a function, variable, or data member and a prvalue otherwise. @@ -495,20 +495,20 @@ member. The type of the result is the type of the member. The result is an lvalue if the member is a static member function or a data member and a prvalue otherwise. -\enternote +\begin{note} a class member can be referred to using a \grammarterm{qualified-id} at any point in its potential scope~(\ref{basic.scope.class}). -\exitnote +\end{note} Where \grammarterm{class-name} \tcode{::\tilde}~\grammarterm{class-name} is used, the two \grammarterm{class-name}{s} shall refer to the same class; this notation names the destructor~(\ref{class.dtor}). The form \tcode{\tilde}~\grammarterm{decltype-specifier} also denotes the destructor, but it shall not be used as the \grammarterm{unqualified-id} in a \grammarterm{qualified-id}. -\enternote +\begin{note} a \grammarterm{typedef-name} that names a class is a \grammarterm{class-name}~(\ref{class.name}). -\exitnote +\end{note} \pnum The \grammarterm{nested-name-specifier} \tcode{::} names the global namespace. @@ -554,7 +554,7 @@ \item if that \grammarterm{id-expression} denotes a non-static data member and it appears in an unevaluated operand. -\enterexample +\begin{example} \begin{codeblock} struct S { @@ -563,7 +563,7 @@ int i = sizeof(S::m); // OK int j = sizeof(S::m + 42); // OK \end{codeblock} -\exitexample +\end{example} \end{itemize} \rSec2[expr.prim.lambda]{Lambda expressions}% @@ -571,7 +571,7 @@ \pnum Lambda expressions provide a concise way to create simple function objects. -\enterexample +\begin{example} \begin{codeblock} #include @@ -583,7 +583,7 @@ }); } \end{codeblock} -\exitexample +\end{example} \begin{bnf} \nontermdef{lambda-expression}\br @@ -644,7 +644,7 @@ In the \grammarterm{decl-specifier-seq} of the \grammarterm{lambda-declarator}, each \grammarterm{decl-specifier} shall either be \tcode{mutable} or \tcode{constexpr}. -\enterexample +\begin{example} \begin{codeblock} auto monoid = [](auto v) { return [=] { return v; }; }; auto add = [](auto m1) constexpr { @@ -669,7 +669,7 @@ static_assert(add(one)(one)() == two()); // ill-formed: \tcode{two()} is not a constant expression static_assert(add(one)(one)() == monoid(2)()); // OK \end{codeblock} -\exitexample +\end{example} \pnum The evaluation of a \grammarterm{lambda-expression} results in a prvalue @@ -679,12 +679,12 @@ in an \grammarterm{alias-declaration}, in a typedef declaration, or in the declaration of a function or function template outside its function body and default arguments. -\enternote +\begin{note} The intention is to prevent lambdas from appearing in a signature. -\exitnote -\enternote +\end{note} +\begin{note} A closure object behaves like a function -object~(\ref{function.objects}).\exitnote +object~(\ref{function.objects}).\end{note} \pnum The type of the \grammarterm{lambda-expression} (which is also the type of the @@ -694,10 +694,10 @@ This class type is not an aggregate type~(\ref{dcl.init.aggr}). The closure type is declared in the smallest block scope, class scope, or namespace scope that contains the corresponding -\grammarterm{lambda-expression}. \enternote This determines the set of namespaces and +\grammarterm{lambda-expression}. \begin{note} This determines the set of namespaces and classes associated with the closure type~(\ref{basic.lookup.argdep}). The parameter types of a \grammarterm{lambda-declarator} do not affect these associated namespaces and -classes. \exitnote An implementation may define the closure type differently from what +classes. \end{note} An implementation may define the closure type differently from what is described below provided this does not alter the observable behavior of the program other than by changing: @@ -723,14 +723,14 @@ type specified by the \grammarterm{trailing-return-type} if provided and/or deduced from \tcode{return} statements as described in~\ref{dcl.spec.auto}. -\enterexample +\begin{example} \begin{codeblock} auto x1 = [](int i){ return i; }; // OK: return type is \tcode{int} auto x2 = []{ return { 1, 2 }; }; // error: deducing return type from \grammarterm{braced-init-list} int j; auto x3 = []()->auto&& { return j; }; // OK: return type is \tcode{int\&} \end{codeblock} -\exitexample +\end{example} \pnum The closure type for a non-generic \grammarterm{lambda-expression} has a public @@ -752,7 +752,7 @@ \tcode{auto} in the \grammarterm{decl-specifier}{s} of the \grammarterm{parameter-declaration-clause} with the name of the corresponding invented \grammarterm{template-parameter}. -\enterexample +\begin{example} \begin{codeblock} auto glambda = [](auto a, auto&& b) { return a < b; }; bool b = glambda(3, 3.14); // OK @@ -770,7 +770,7 @@ auto q = p(1, 'a', 3.14); // OK: outputs \tcode{1a3.14} q(); // OK: outputs \tcode{1a3.14} \end{codeblock} -\exitexample +\end{example} This function call operator or operator template is declared \tcode{const}~(\ref{class.mfct.non-static}) if and only if the \grammarterm{lambda-expression}'s \grammarterm{parameter-declaration-clause} is not @@ -784,10 +784,10 @@ the corresponding \grammarterm{lambda-expression}{'s} \grammarterm{parameter-declaration-clause} is followed by \tcode{constexpr}, or it satisfies the requirements for a constexpr function~(\ref{dcl.constexpr}). -\enternote Names referenced in +\begin{note} Names referenced in the \grammarterm{lambda-declarator} are looked up in the context in which the -\grammarterm{lambda-expression} appears. \exitnote -\enterexample +\grammarterm{lambda-expression} appears. \end{note} +\begin{example} \begin{codeblock} auto ID = [](auto a) { return a; }; static_assert(ID(3) == 3); // OK @@ -798,7 +798,7 @@ }; static_assert(ID(NonLiteral{3}).n == 3); // ill-formed \end{codeblock} -\exitexample +\end{example} \pnum The closure type for a non-generic \grammarterm{lambda-expression} with no @@ -822,7 +822,7 @@ the pointer to function shall behave as if it were a \grammarterm{decltype-specifier} denoting the return type of the corresponding function call operator template specialization. -\enternote +\begin{note} If the generic lambda has no \grammarterm{trailing-return-type} or the \grammarterm{trailing-return-type} contains a placeholder type, return type deduction of the corresponding function call operator template specialization @@ -850,9 +850,9 @@ { return &lambda_call_operator_invoker; } }; \end{codeblock} -\exitnote +\end{note} -\enterexample +\begin{example} \begin{codeblock} void f1(int (*)(int)) { } void f2(char (*)(int)) { } @@ -870,7 +870,7 @@ h(glambda); // OK: calls \#3 since it is convertible from ID int& (*fpi)(int*) = [](auto* a) -> auto& { return *a; }; // OK \end{codeblock} -\exitexample +\end{example} The value returned by any given specialization of this conversion function template is the address of a function \tcode{F} that, when invoked, has the same @@ -878,23 +878,23 @@ template specialization. \tcode{F} is a constexpr function if the corresponding specialization is a constexpr function. -\enternote +\begin{note} This will result in the implicit instantiation of the generic lambda's body. The instantiated generic lambda's return type and parameter types shall match the return type and parameter types of the pointer to function. -\exitnote -\enterexample +\end{note} +\begin{example} \begin{codeblock} auto GL = [](auto a) { std::cout << a; return a; }; int (*GL_int)(int) = GL; // OK: through conversion function template GL_int(3); // OK: same as \tcode{GL(3)} \end{codeblock} -\exitexample +\end{example} The conversion function or conversion function template is public, constexpr, non-virtual, non-explicit, const, and has a non-throwing exception specification~(\ref{except.spec}). -\enterexample +\begin{example} \begin{codeblock} auto Fwd = [](int (*fp)(int), auto a) { return fp(a); }; auto C = [](auto a) { return a; }; @@ -905,7 +905,7 @@ auto NC = [](auto a) { static int s; return a; }; static_assert(Fwd(NC,3) == 3); // ill-formed \end{codeblock} -\exitexample +\end{example} \pnum The \grammarterm{lambda-expression}'s \grammarterm{compound-statement} yields the @@ -914,7 +914,7 @@ \tcode{this}~(\ref{class.this}) and transforming \grammarterm{id-expression}{s} referring to non-static class members into class member access expressions using \tcode{(*this)}~(\ref{class.mfct.non-static}), the \grammarterm{compound-statement} is -considered in the context of the \grammarterm{lambda-expression}. \enterexample +considered in the context of the \grammarterm{lambda-expression}. \begin{example} \begin{codeblock} struct S1 { @@ -928,7 +928,7 @@ } }; \end{codeblock} -\exitexample +\end{example} Further, a variable \tcode{__func__} is implicitly defined at the beginning of the \grammarterm{compound-statement} of the \grammarterm{lambda-expression}, with semantics as described in~\ref{dcl.fct.def.general}. @@ -941,12 +941,12 @@ \grammarterm{capture-default} that is \tcode{=}, each \grammarterm{simple-capture} of that \grammarterm{lambda-capture} shall be of the form ``\tcode{\&} \grammarterm{identifier}'' or ``\tcode{* this}''. -\enternote The form \tcode{[\&,this]} is redundant but accepted -for compatibility with ISO \CppXIV. \exitnote +\begin{note} The form \tcode{[\&,this]} is redundant but accepted +for compatibility with ISO \CppXIV. \end{note} Ignoring appearances in \grammarterm{initializer}{s} of \grammarterm{init-capture}{s}, an identifier or \tcode{this} shall not appear more than once in a -\grammarterm{lambda-capture}. \enterexample +\grammarterm{lambda-capture}. \begin{example} \begin{codeblock} struct S2 { void f(int i); }; @@ -959,7 +959,7 @@ [this, *this]{ }; // error: \tcode{this} appears twice } \end{codeblock} -\exitexample +\end{example} \pnum A \grammarterm{lambda-expression} whose smallest enclosing scope is a block @@ -968,8 +968,8 @@ \grammarterm{simple-capture} in its \grammarterm{lambda-introducer}. The \defn{reaching scope} of a local lambda expression is the set of enclosing scopes up to and including the innermost enclosing function and -its parameters. \enternote This reaching scope includes any intervening -\grammarterm{lambda-expression}{s}. \exitnote +its parameters. \begin{note} This reaching scope includes any intervening +\grammarterm{lambda-expression}{s}. \end{note} \pnum The \grammarterm{identifier} in a \grammarterm{simple-capture} is looked up using the @@ -996,12 +996,12 @@ \item if the capture is by reference, the variable's lifetime ends when the closure object's lifetime ends. \end{itemize} -\enternote +\begin{note} This enables an \grammarterm{init-capture} like ``\tcode{x = std::move(x)}''; the second ``\tcode{x}'' must bind to a declaration in the surrounding context. -\exitnote -\enterexample +\end{note} +\begin{example} \begin{codeblock} int x = 4; auto y = [&r = x, x = x+1]()->int { @@ -1009,7 +1009,7 @@ return x+2; }(); // Updates \tcode{::x} to 6, and initializes \tcode{y} to 7. \end{codeblock} -\exitexample +\end{example} \pnum A \grammarterm{lambda-expression} with an associated @@ -1029,7 +1029,7 @@ a generic lambda parameter declared within the reaching scope of the \grammarterm{lambda-expression}. \end{itemize} -\enterexample +\begin{example} \begin{codeblock} void f(int, const int (&)[2] = {}) { } // \#1 void f(const int&, const int (&)[1]) { } // \#2 @@ -1045,13 +1045,13 @@ }; } \end{codeblock} -\exitexample +\end{example} All such implicitly captured entities shall be declared within the reaching scope of the lambda expression. -\enternote The implicit capture of an entity by a nested +\begin{note} The implicit capture of an entity by a nested \grammarterm{lambda-expression} can cause its implicit capture by the containing \grammarterm{lambda-expression} (see below). Implicit odr-uses of \tcode{this} can result -in implicit capture. \exitnote +in implicit capture. \end{note} \pnum An entity is \defn{captured} if it is captured explicitly or implicitly. An entity @@ -1064,7 +1064,7 @@ entity shall be captured by the \grammarterm{lambda-expression}. If a \grammarterm{lambda-expression} captures an entity and that entity is not defined or captured in the immediately enclosing lambda expression or function, the program is -ill-formed. \enterexample +ill-formed. \begin{example} \begin{codeblock} void f1(int i) { int const N = 20; @@ -1112,11 +1112,11 @@ } }; \end{codeblock} -\exitexample +\end{example} \pnum A \grammarterm{lambda-expression} appearing in a default argument shall not -implicitly or explicitly capture any entity. \enterexample +implicitly or explicitly capture any entity. \begin{example} \begin{codeblock} void f2() { @@ -1128,7 +1128,7 @@ void g5(int = ([]{ return sizeof i; })()); // OK } \end{codeblock} -\exitexample +\end{example} \pnum An entity is \defnx{captured by copy}{captured!by~copy} if @@ -1156,14 +1156,14 @@ \grammarterm{lambda-expression} that is an odr-use~(\ref{basic.def.odr}) of an entity captured by copy is transformed into an access to the corresponding unnamed data member of the closure type. -\enternote An \grammarterm{id-expression} that is not an odr-use refers to +\begin{note} An \grammarterm{id-expression} that is not an odr-use refers to the original entity, never to a member of the closure type. Furthermore, such an \grammarterm{id-expression} does not cause the implicit capture of the -entity. \exitnote +entity. \end{note} If \tcode{*this} is captured by copy, each odr-use of \tcode{this} is transformed into a pointer to the corresponding unnamed data member of the closure type, -cast~(\ref{expr.cast}) to the type of \tcode{this}. \enternote The cast ensures that the -transformed expression is a prvalue. \exitnote \enterexample +cast~(\ref{expr.cast}) to the type of \tcode{this}. \begin{note} The cast ensures that the +transformed expression is a prvalue. \end{note} \begin{example} \begin{codeblock} void f(const int*); void g() { @@ -1175,7 +1175,7 @@ }; } \end{codeblock} -\exitexample +\end{example} \pnum An entity is \defnx{captured by reference}{captured!by~reference} if it is implicitly or explicitly @@ -1183,12 +1183,12 @@ non-static data members are declared in the closure type for entities captured by reference. If declared, such non-static data members shall be of literal type. -\enterexample +\begin{example} \begin{codeblock} // The inner closure type must be a literal type regardless of how reference captures are represented. static_assert([](int n) { return [&n] { return ++n; }(); }(3) == 4); \end{codeblock} -\exitexample +\end{example} A member of an anonymous union shall not be captured by reference. \pnum @@ -1206,7 +1206,7 @@ \tcode{m2} captures the same entity captured by \tcode{m1}. \end{itemize} -\enterexample the nested lambda expressions and invocations below will output +\begin{example} the nested lambda expressions and invocations below will output \tcode{123234}. \begin{codeblock} int a = 1, b = 1, c = 1; @@ -1222,14 +1222,14 @@ m1(); std::cout << a << b << c; \end{codeblock} -\exitexample +\end{example} \pnum Every occurrence of \tcode{decltype((x))} where \tcode{x} is a possibly parenthesized \grammarterm{id-expression} that names an entity of automatic storage duration is treated as if \tcode{x} were transformed into an access to a corresponding data member of the closure type that would have been declared if \tcode{x} were an odr-use of -the denoted entity. \enterexample +the denoted entity. \begin{example} \begin{codeblock} void f3() { @@ -1243,14 +1243,14 @@ }; } \end{codeblock} -\exitexample +\end{example} \pnum The closure type associated with a \grammarterm{lambda-expression} has no default constructor and a deleted copy assignment operator. It has a defaulted copy constructor and a defaulted move constructor~(\ref{class.copy}). -\enternote These special member functions are implicitly defined as -usual, and might therefore be defined as deleted. \exitnote +\begin{note} These special member functions are implicitly defined as +usual, and might therefore be defined as deleted. \end{note} \pnum The closure type associated with a \grammarterm{lambda-expression} has an @@ -1269,21 +1269,21 @@ \grammarterm{init-capture}{s} are initialized as indicated by the corresponding \grammarterm{initializer} (which may be copy- or direct-initialization). (For array members, the array elements are direct-initialized in increasing subscript order.) These initializations are performed -in the (unspecified) order in which the non-static data members are declared. \enternote +in the (unspecified) order in which the non-static data members are declared. \begin{note} This ensures that the destructions will occur in the reverse order of the constructions. -\exitnote +\end{note} \pnum -\enternote If an entity is implicitly or explicitly captured by reference, +\begin{note} If an entity is implicitly or explicitly captured by reference, invoking the function call operator of the corresponding \grammarterm{lambda-expression} after the lifetime of the entity has ended is likely to result in undefined behavior. -\exitnote +\end{note} \pnum A \grammarterm{simple-capture} followed by an ellipsis is a pack expansion~(\ref{temp.variadic}). An \grammarterm{init-capture} followed by an ellipsis is ill-formed. -\enterexample +\begin{example} \begin{codeblock} template void f(Args... args) { @@ -1291,7 +1291,7 @@ lm(); } \end{codeblock} -\exitexample% +\end{example}% \indextext{expression!lambda|)}% \indextext{expression!primary|)} @@ -1350,7 +1350,7 @@ the expression is called a \defn{binary left fold}. If \tcode{e1} contains an unexpanded parameter pack, the expression is called a \defn{binary right fold}. -\enterexample +\begin{example} \begin{codeblock} template bool f(Args ...args) { @@ -1362,7 +1362,7 @@ return (args + ... + args); // error: both operands contain unexpanded parameter packs } \end{codeblock} -\exitexample +\end{example} \indextext{expression!fold|)} \rSec1[expr.post]{Postfix expressions}% @@ -1410,12 +1410,12 @@ \end{bnf} \pnum -\enternote The \tcode{>} token following the +\begin{note} The \tcode{>} token following the \nonterminal{type-id} in a \tcode{dynamic_cast}, \tcode{static_cast}, \tcode{reinterpret_cast}, or \tcode{const_cast} may be the product of replacing a \tcode{>{>}} token by two consecutive \tcode{>} -tokens~(\ref{temp.names}).\exitnote +tokens~(\ref{temp.names}).\end{note} \rSec2[expr.sub]{Subscripting} @@ -1433,10 +1433,10 @@ \tcode{\&x[0]}.} The expression \tcode{E1[E2]} is identical (by definition) to \tcode{*((E1)+(E2))} -\enternote +\begin{note} see~\ref{expr.unary} and~\ref{expr.add} for details of \tcode{*} and \tcode{+} and~\ref{dcl.array} for details of arrays. -\exitnote, except that in the case of an array operand, the result is an lvalue +\end{note}, except that in the case of an array operand, the result is an lvalue if that operand is an lvalue and an xvalue otherwise. \pnum @@ -1470,10 +1470,10 @@ the class object referred to by the object expression. In the case of an implicit class member access, the implied object is the one pointed to by \tcode{this}. -\enternote +\begin{note} a member function call of the form \tcode{f()} is interpreted as \tcode{(*this).f()} (see~\ref{class.mfct.non-static}). -\exitnote +\end{note} If a function or member function name is used, the name can be overloaded (Clause~\ref{over}), in which case the appropriate function shall be selected according to the rules in~\ref{over.match}. If the selected @@ -1482,21 +1482,21 @@ called. Otherwise, its final overrider~(\ref{class.virtual}) in the dynamic type of the object expression is called; such a call is referred to as a \defnx{virtual function call}{function!virtual function~call}. -\enternote +\begin{note} the dynamic type is the type of the object referred to by the current value of the object expression. \ref{class.cdtor}~describes the behavior of virtual function calls when the object expression refers to an object under construction or destruction. -\exitnote +\end{note} \pnum -\enternote +\begin{note} If a function or member function name is used, and name lookup~(\ref{basic.lookup}) does not find a declaration of that name, the program is ill-formed. No function is implicitly declared by such a call. -\exitnote +\end{note} \pnum If the \grammarterm{postfix-expression} designates a destructor~(\ref{class.dtor}), @@ -1515,26 +1515,26 @@ When a function is called, each parameter~(\ref{dcl.fct}) shall be initialized~(\ref{dcl.init},~\ref{class.copy},~\ref{class.ctor}) with its corresponding argument. -\enternote Such initializations are indeterminately sequenced -with respect to each other~(\ref{intro.execution}) \exitnote +\begin{note} Such initializations are indeterminately sequenced +with respect to each other~(\ref{intro.execution}) \end{note} If the function is a non-static member function, the \tcode{this} parameter of the function~(\ref{class.this}) shall be initialized with a pointer to the object of the call, converted as if by an explicit type conversion~(\ref{expr.cast}). -\enternote +\begin{note} There is no access or ambiguity checking on this conversion; the access checking and disambiguation are done as part of the (possibly implicit) class member access operator. See~\ref{class.member.lookup},~\ref{class.access.base}, and~\ref{expr.ref}. -\exitnote +\end{note} When a function is called, the parameters that have object type shall have completely-defined object type. -\enternote +\begin{note} this still allows a parameter to be a pointer or reference to an incomplete class type. However, it prevents a passed-by-value parameter to have an incomplete class type. -\exitnote +\end{note} During the initialization of a parameter, an implementation may avoid the construction of extra temporaries by combining the conversions on the associated argument and/or the construction of temporaries with the @@ -1542,7 +1542,7 @@ lifetime of a parameter ends when the function in which it is defined returns. The initialization and destruction of each parameter occurs within the context of the calling function. -\enterexample +\begin{example} the access of the constructor, conversion functions or destructor is checked at the point of call in the calling function. If a constructor or destructor for a function parameter throws an exception, the search @@ -1550,7 +1550,7 @@ particular, if the function called has a \grammarterm{function-try-block} (Clause~\ref{except}) with a handler that could handle the exception, this handler is not considered. -\exitexample +\end{example} The value of a function call is the value returned by the called function except in a virtual function call if the return type of the final overrider is different from the return type of the statically @@ -1558,7 +1558,7 @@ converted to the return type of the statically chosen function. \pnum -\enternote +\begin{note} \indextext{type~checking!argument}% \indextext{function~call}% \indextext{argument~passing}% @@ -1575,7 +1575,7 @@ needed~(\ref{dcl.type},~\ref{lex.literal},~\ref{lex.string},~\ref{dcl.array},~\ref{class.temporary}). In addition, it is possible to modify the values of nonconstant objects through pointer parameters. -\exitnote +\end{note} \pnum \indextext{declaration!ellipsis~in function}% @@ -1584,20 +1584,20 @@ arguments~(\ref{dcl.fct.default})) or more arguments (by using the ellipsis, \tcode{...}, or a function parameter pack~(\ref{dcl.fct})) than the number of parameters in the function definition~(\ref{dcl.fct.def}). -\enternote +\begin{note} this implies that, except where the ellipsis (\tcode{...}) or a function parameter pack is used, a parameter is available for each argument. -\exitnote +\end{note} \pnum \indextext{ellipsis!conversion~sequence}% When there is no parameter for a given argument, the argument is passed in such a way that the receiving function can obtain the value of the argument by invoking \tcode{va_arg}~(\ref{support.runtime}). -\enternote This paragraph does not apply to arguments passed to a function parameter pack. +\begin{note} This paragraph does not apply to arguments passed to a function parameter pack. Function parameter packs are expanded during template instantiation~(\ref{temp.variadic}), thus each such argument has a corresponding parameter when a function template -specialization is actually called. \exitnote +specialization is actually called. \end{note} The lvalue-to-rvalue~(\ref{conv.lval}), array-to-pointer~(\ref{conv.array}), and function-to-pointer~(\ref{conv.func}) standard conversions are @@ -1621,14 +1621,14 @@ \pnum \indextext{evaluation!order~of argument}% \indextext{evaluation!unspecified order~of function~call}% -\enternote +\begin{note} The evaluations of the postfix expression and of the arguments are all unsequenced relative to one another. \indextext{evaluation!unspecified order~of argument}% All side effects of argument evaluations are sequenced before the function is entered (see~\ref{intro.execution}). -\exitnote +\end{note} \pnum \indextext{function~call!recursive}% @@ -1652,14 +1652,14 @@ \grammarterm{decltype-specifier}, \end{itemize} a temporary object is not introduced for the prvalue. The type of the prvalue -may be incomplete. \enternote as a result, storage is not allocated for the +may be incomplete. \begin{note} as a result, storage is not allocated for the prvalue and it is not destroyed; thus, a class type is not instantiated as a result of being the type of a function call in this context. This is true regardless of whether the expression uses function call notation or operator -notation~(\ref{over.match.oper}). \exitnote \enternote unlike the rule for +notation~(\ref{over.match.oper}). \end{note} \begin{note} unlike the rule for a \grammarterm{decltype-specifier} that considers whether an \grammarterm{id-expression} is parenthesized~(\ref{dcl.type.simple}), parentheses have no special meaning -in this context. \exitnote +in this context. \end{note} \item otherwise, the type of the prvalue shall be complete. \end{itemize} @@ -1695,11 +1695,11 @@ specified type, whose value is that produced by value-initializing~(\ref{dcl.init}) an object of type \tcode{T}; no initialization is done for the \tcode{void()} case. -\enternote +\begin{note} if \tcode{T} is a non-class type that is cv-qualified, the \grammarterm{cv-qualifier}{s} are discarded when determining the type of the resulting prvalue (Clause~\ref{expr}). -\exitnote +\end{note} \pnum Similarly, a \grammarterm{simple-type-specifier} or @@ -1776,15 +1776,15 @@ In either case, the \grammarterm{id-expression} shall name a member of the class or of one of its base classes. -\enternote +\begin{note} because the name of a class is inserted in its class scope (Clause~\ref{class}), the name of a class is also considered a nested member of that class. -\exitnote -\enternote +\end{note} +\begin{note} \ref{basic.lookup.classref} describes how names are looked up after the \tcode{.} and \tcode{->} operators. -\exitnote +\end{note} \pnum Abbreviating \term{postfix-expression.id-expression} @@ -1842,8 +1842,8 @@ \tcode{E1.E2} is a prvalue. The expression designates a non-static member function. The expression can be used only as the left-hand operand of a member function call~(\ref{class.mfct}). -\enternote Any redundant set of parentheses surrounding the expression -is ignored~(\ref{expr.prim}). \exitnote The type of \tcode{E1.E2} is +\begin{note} Any redundant set of parentheses surrounding the expression +is ignored~(\ref{expr.prim}). \end{note} The type of \tcode{E1.E2} is ``function of parameter-type-list \cvqual{cv} returning \tcode{T}''. \end{itemize} @@ -1860,10 +1860,10 @@ function, the program is ill-formed if the class of which \tcode{E2} is directly a member is an ambiguous base~(\ref{class.member.lookup}) of the naming class~(\ref{class.access.base}) of \tcode{E2}. -\enternote +\begin{note} The program is also ill-formed if the naming class is an ambiguous base of the class type of the object expression; see~\ref{class.access.base}. -\exitnote +\end{note} \rSec2[expr.post.incr]{Increment and decrement} @@ -1874,9 +1874,9 @@ \indextext{postfix~\tcode{++}}% The value of a postfix \tcode{++} expression is the value of its operand. -\enternote +\begin{note} the value obtained is a copy of the original value -\exitnote +\end{note} The operand shall be a modifiable lvalue. The type of the operand shall be an arithmetic type other than \cv\ \tcode{bool}, or a pointer to a complete object type. The value @@ -1888,11 +1888,11 @@ indeterminately-sequenced function call, the operation of postfix \tcode{++} is a single evaluation. -\enternote +\begin{note} Therefore, a function call shall not intervene between the lvalue-to-rvalue conversion and the side effect associated with any single postfix ++ operator. -\exitnote +\end{note} The result is a prvalue. The type of the result is the cv-unqualified version of the type of the operand. If the operand is a bit-field that cannot represent the incremented value, the @@ -1908,9 +1908,9 @@ \indextext{postfix~\tcode{\dcr}}% The operand of postfix \tcode{\dcr} is decremented analogously to the postfix \tcode{++} operator. -\enternote +\begin{note} For prefix increment and decrement, see~\ref{expr.pre.incr}. -\exitnote +\end{note} \rSec2[expr.dynamic.cast]{Dynamic cast} @@ -1960,7 +1960,7 @@ reference cases, the program is ill-formed if \cvqual{cv2} has greater cv-qualification than \cvqual{cv1} or if \tcode{B} is an inaccessible or ambiguous base class of \tcode{D}. -\enterexample +\begin{example} \begin{codeblock} struct B { }; @@ -1969,7 +1969,7 @@ B* bp = dynamic_cast(dp); // equivalent to \tcode{B* bp = dp;} } \end{codeblock} -\exitexample +\end{example} \pnum Otherwise, \tcode{v} shall be a pointer to or a glvalue of a polymorphic @@ -2010,7 +2010,7 @@ \indextext{\idxcode{bad_cast}}% \indexlibrary{\idxcode{bad_cast}}% -\enterexample +\begin{example} \begin{codeblock} class A { virtual void f(); }; @@ -2038,11 +2038,11 @@ E* ep1 = dynamic_cast(ap); // succeeds } \end{codeblock} -\exitexample -\enternote +\end{example} +\begin{note} \ref{class.cdtor} describes the behavior of a \tcode{dynamic_cast} applied to an object under construction or destruction. -\exitnote +\end{note} \rSec2[expr.typeid]{Type identification} @@ -2107,7 +2107,7 @@ cv-qualified type, the result of the \tcode{typeid} expression refers to a \tcode{std::type_info} object representing the cv-unqualified type. -\enterexample +\begin{example} \begin{codeblock} class D @\tcode{\{ /* ... */ \}}@; @@ -2119,17 +2119,17 @@ typeid(D) == typeid(d2); // yields \tcode{true} typeid(D) == typeid(const D&); // yields \tcode{true} \end{codeblock} -\exitexample +\end{example} \pnum If the header \tcode{}~(\ref{type.info}) is not included prior to a use of \tcode{typeid}, the program is ill-formed. \pnum -\enternote +\begin{note} \ref{class.cdtor} describes the behavior of \tcode{typeid} applied to an object under construction or destruction. -\exitnote +\end{note} \rSec2[expr.static.cast]{Static cast} @@ -2165,7 +2165,7 @@ of type ``\cvqual{cv1} \tcode{B}'' is actually a subobject of an object of type \tcode{D}, the result refers to the enclosing object of type \tcode{D}. Otherwise, the behavior is undefined. -\enterexample +\begin{example} \begin{codeblock} struct B { }; @@ -2175,7 +2175,7 @@ static_cast(br); // produces lvalue to the original \tcode{d} object \end{codeblock} -\exitexample +\end{example} \pnum A glvalue, class prvalue, or array prvalue @@ -2205,10 +2205,10 @@ \end{codeblock} for some invented temporary variable \tcode{t}~(\ref{dcl.init}) and then using the temporary variable as the result of the conversion. -\enternote +\begin{note} The conversion is ill-formed when attempting to convert an expression of class type to an inaccessible or ambiguous base class. -\exitnote +\end{note} The expression \tcode{e} is used as a glvalue if and only if the initialization uses it as a glvalue. @@ -2221,13 +2221,13 @@ Any expression can be explicitly converted to type \cv\ \tcode{void}, in which case it becomes a discarded-value expression (Clause~\ref{expr}). -\enternote +\begin{note} however, if the value is in a temporary object~(\ref{class.temporary}), the destructor for that object is not executed until the usual time, and the value of the object is preserved for the purpose of executing the destructor. -\exitnote +\end{note} \pnum @@ -2241,7 +2241,7 @@ conversion, can be performed explicitly using \tcode{static_cast}. A program is ill-formed if it uses \tcode{static_cast} to perform the inverse of an ill-formed standard conversion sequence. -\enterexample +\begin{example} \begin{codeblock} struct B { }; struct D : private B { }; @@ -2250,7 +2250,7 @@ static_cast((int D::*)0); // Error: B is a private base of D. } \end{codeblock} -\exitexample +\end{example} \pnum The lvalue-to-rvalue~(\ref{conv.lval}), @@ -2323,12 +2323,12 @@ contains the original member, or is a base or derived class of the class containing the original member, the resulting pointer to member points to the original member. Otherwise, the behavior is undefined. -\enternote +\begin{note} although class \tcode{B} need not contain the original member, the dynamic type of the object with which indirection through the pointer to member is performed must contain the original member; see~\ref{expr.mptr.oper}. -\exitnote +\end{note} \pnum A prvalue of type ``pointer to \cvqual{cv1} \tcode{void}'' can be @@ -2344,14 +2344,14 @@ A value of type pointer to object converted to ``pointer to \cvqual{cv} \tcode{void}'' and back, possibly with different cv-qualification, shall have its original value. -\enterexample +\begin{example} \begin{codeblock} T* p1 = new T; const T* p2 = static_cast(static_cast(p1)); bool b = p1 == p2; // \tcode{b} will have the value \tcode{true}. \end{codeblock} -\exitexample +\end{example} \rSec2[expr.reinterpret.cast]{Reinterpret cast} @@ -2378,10 +2378,10 @@ its operand. \pnum -\enternote +\begin{note} The mapping performed by \tcode{reinterpret_cast} might, or might not, produce a representation different from the original value. -\exitnote +\end{note} \pnum \indextext{cast!reinterpret!pointer to integer}% @@ -2390,14 +2390,14 @@ to hold it. \indextext{conversion!implementation~defined pointer integer}% The mapping function is implementa\-tion-defined. -\enternote +\begin{note} It is intended to be unsurprising to those who know the addressing structure of the underlying machine. -\exitnote A value of type \tcode{std::nullptr_t} can be converted to an integral +\end{note} A value of type \tcode{std::nullptr_t} can be converted to an integral type; the conversion has the same meaning and validity as a conversion of -\tcode{(void*)0} to the integral type. \enternote A \tcode{reinterpret_cast} +\tcode{(void*)0} to the integral type. \begin{note} A \tcode{reinterpret_cast} cannot be used to convert a value of any type to the type -\tcode{std::nullptr_t}. \exitnote +\tcode{std::nullptr_t}. \end{note} \pnum \indextext{cast!reinterpret!integer~to pointer}% @@ -2409,8 +2409,8 @@ \indextext{conversion!implementation~defined pointer integer}% mappings between pointers and integers are otherwise \impldef{conversions between pointers and integers}. -\enternote Except as described in \ref{basic.stc.dynamic.safety}, the result of -such a conversion will not be a safely-derived pointer value. \exitnote +\begin{note} Except as described in \ref{basic.stc.dynamic.safety}, the result of +such a conversion will not be a safely-derived pointer value. \end{note} \pnum \indextext{cast!reinterpret!pointer-to-function}% @@ -2426,9 +2426,9 @@ \tcode{T2}'' (where \tcode{T1} and \tcode{T2} are function types) and back to its original type yields the original pointer value, the result of such a pointer conversion is unspecified. -\enternote +\begin{note} see also~\ref{conv.ptr} for more details of pointer conversions. -\exitnote +\end{note} \pnum An object pointer @@ -2458,11 +2458,11 @@ \pnum The null pointer value~(\ref{conv.ptr}) is converted to the null pointer value of the destination type. -\enternote +\begin{note} A null pointer constant of type \tcode{std::nullptr_t} cannot be converted to a pointer type, and a null pointer constant of integral type is not necessarily converted to a null pointer value. -\exitnote +\end{note} \pnum \indextext{cast!reinterpret!pointer-to-member}% @@ -2497,11 +2497,11 @@ \tcode{T1}'' can be explicitly converted to the type ``pointer to \tcode{T2}'' using a \tcode{reinterpret_cast}. The result refers to the same object as the source glvalue, but with the specified -type. \enternote That is, for lvalues, a reference cast +type. \begin{note} That is, for lvalues, a reference cast \tcode{reinterpret_cast(x)} has the same effect as the conversion \tcode{*reinterpret_cast(\&x)} with the built-in \tcode{\&} and \tcode{*} operators (and similarly for -\tcode{reinterpret_cast(x)}). \exitnote No +\tcode{reinterpret_cast(x)}). \end{note} No temporary is created, no copy is made, and constructors~(\ref{class.ctor}) or conversion functions~(\ref{class.conv}) are not called.\footnote{This @@ -2524,17 +2524,17 @@ performed explicitly using \tcode{const_cast}. \pnum -\enternote +\begin{note} Subject to the restrictions in this section, an expression may be cast to its own type using a \tcode{const_cast} operator. -\exitnote +\end{note} \pnum For two similar types \tcode{T1} and \tcode{T2}~(\ref{conv.qual}), a prvalue of type \tcode{T1} may be explicitly converted to the type \tcode{T2} using a \tcode{const_cast}. The result of a \tcode{const_cast} refers to the original entity. -\enterexample +\begin{example} \begin{codeblock} typedef int *A[3]; // array of 3 pointer to \tcode{int} typedef const int *const CA[3]; // array of 3 const pointer to \tcode{const int} @@ -2543,7 +2543,7 @@ A &&r1 = const_cast(CA{}); // error: temporary array decayed to pointer A &&r2 = const_cast(CA{}); // OK \end{codeblock} -\exitexample +\end{example} \pnum For two object types \tcode{T1} and \tcode{T2}, if a pointer to \tcode{T1} can @@ -2572,14 +2572,14 @@ the destination type. \pnum -\enternote +\begin{note} Depending on the type of the object, a write operation through the pointer, lvalue or pointer to data member resulting from a \tcode{const_cast} that casts away a const-qualifier\footnote{\tcode{const_cast} is not limited to conversions that cast away a const-qualifier.} may produce undefined behavior~(\ref{dcl.type.cv}). -\exitnote +\end{note} \pnum \indextext{\idxcode{const}!cast away}% @@ -2609,7 +2609,7 @@ \tcode{T2}'' casts away constness. \pnum -\enternote +\begin{note} some conversions which involve only changes in cv-qualification cannot be done using \tcode{const_cast.} For instance, conversions between pointers to functions are not covered because such conversions lead to @@ -2617,7 +2617,7 @@ conversions between pointers to member functions, and in particular, the conversion from a pointer to a const member function to a pointer to a non-const member function, are not covered. -\exitnote% +\end{note}% \indextext{expression!postfix|)} \rSec1[expr.unary]{Unary expressions} @@ -2678,13 +2678,13 @@ referring to the object or function to which the expression points. If the type of the expression is ``pointer to \tcode{T}'', the type of the result is ``\tcode{T}''. -\enternote +\begin{note} \indextext{type!incomplete}% indirection through a pointer to an incomplete type (other than \cvqual{cv} \tcode{void}) is valid. The lvalue thus obtained can be used in limited ways (to initialize a reference, for example); this lvalue must not be converted to a prvalue, see~\ref{conv.lval}. -\exitnote +\end{note} \pnum The result of each of the following unary operators is a prvalue. @@ -2699,15 +2699,15 @@ of class \tcode{C} of type \tcode{T}'' and is a prvalue designating \tcode{C::m}. Otherwise, if the type of the expression is \tcode{T}, the result has type ``pointer to \tcode{T}'' and is a prvalue that is the address of the designated object~(\ref{intro.memory}) -or a pointer to the designated function. \enternote In particular, the address of an +or a pointer to the designated function. \begin{note} In particular, the address of an object of type ``\cv\ \tcode{T}'' is ``pointer to \cv\ \tcode{T}'', with the same -cv-qualification. \exitnote +cv-qualification. \end{note} For purposes of pointer arithmetic~(\ref{expr.add}) and comparison~(\ref{expr.rel}, \ref{expr.eq}), an object that is not an array element whose address is taken in this way is considered to belong to an array with one element of type \tcode{T}. -\enterexample +\begin{example} \begin{codeblock} struct A { int i; }; @@ -2718,18 +2718,18 @@ int* p2 = p1 + 1; // defined behavior bool b = p2 > p1; // defined behavior, with value \tcode{true} \end{codeblock} -\exitexample -\enternote +\end{example} +\begin{note} a pointer to member formed from a \tcode{mutable} non-static data member~(\ref{dcl.stc}) does not reflect the \tcode{mutable} specifier associated with the non-static data member. -\exitnote +\end{note} \pnum A pointer to member is only formed when an explicit \tcode{\&} is used and its operand is a \grammarterm{qualified-id} not enclosed in parentheses. -\enternote +\begin{note} that is, the expression \tcode{\&(qualified-id)}, where the \grammarterm{qualified-id} is enclosed in parentheses, does not form an expression of type ``pointer to member''. Neither does @@ -2739,7 +2739,7 @@ type to the type ``pointer to function''~(\ref{conv.func}). Nor is \tcode{\&unqualified-id} a pointer to member, even within the scope of the \grammarterm{unqualified-id}'s class. -\exitnote +\end{note} \pnum If \tcode{\&} is applied to an lvalue of incomplete class type and the @@ -2752,12 +2752,12 @@ The address of an overloaded function (Clause~\ref{over}) can be taken only in a context that uniquely determines which version of the overloaded function is referred to (see~\ref{over.over}). -\enternote +\begin{note} since the context might determine whether the operand is a static or non-static member function, the context can also affect whether the expression has type ``pointer to function'' or ``pointer to member function''. -\exitnote +\end{note} \pnum \indextext{operator!unary~plus}% @@ -2794,13 +2794,13 @@ The ambiguity is resolved by treating \tcode{\~{}} as the unary complement operator rather than as the start of an \grammarterm{unqualified-id} naming a destructor. -\enternote +\begin{note} Because the grammar does not permit an operator to follow the \tcode{.}, \tcode{->}, or \tcode{::} tokens, a \tcode{\~{}} followed by a \grammarterm{class-name} or \grammarterm{decltype-specifier} in a member access expression or \grammarterm{qualified-id} is unambiguously parsed as a destructor name. -\exitnote +\end{note} \rSec2[expr.pre.incr]{Increment and decrement} @@ -2819,10 +2819,10 @@ bit-field if the operand is a bit-field. If \tcode{x} is not of type \tcode{bool}, the expression \tcode{++x} is equivalent to \tcode{x+=1} \indextext{operator!\idxcode{+=}}% -\enternote +\begin{note} See the discussions of addition~(\ref{expr.add}) and assignment operators~(\ref{expr.ass}) for information on conversions. -\exitnote +\end{note} \pnum The operand of prefix @@ -2831,9 +2831,9 @@ The requirements on the operand of prefix \tcode{\dcr} and the properties of its result are otherwise the same as those of prefix \tcode{++}. -\enternote +\begin{note} For postfix increment and decrement, see~\ref{expr.post.incr}. -\exitnote +\end{note} \rSec2[expr.sizeof]{Sizeof} @@ -2856,15 +2856,15 @@ type~(\ref{basic.fundamental}) is \impldef{sizeof applied@\tcode{sizeof} applied to fundamental types other than \tcode{char}, \tcode{signed char}, and \tcode{unsigned char}}. -\enternote +\begin{note} in particular, \tcode{sizeof(bool)}, \tcode{sizeof(char16_t)}, \tcode{sizeof(char32_t)}, and \tcode{sizeof(wchar_t)} are implementation-defined.\footnote{\tcode{sizeof(bool)} is not required to be \tcode{1}.} -\exitnote -\enternote +\end{note} +\begin{note} See~\ref{intro.memory} for the definition of \term{byte} and~\ref{basic.types} for the definition of \term{object representation}. -\exitnote +\end{note} \pnum \indextext{reference!\idxcode{sizeof}}% @@ -2899,7 +2899,7 @@ pack. The \tcode{sizeof...} operator yields the number of arguments provided for the parameter pack \grammarterm{identifier}. A \tcode{sizeof...} expression is a pack expansion~(\ref{temp.variadic}). -\enterexample +\begin{example} \begin{codeblock} template @@ -2907,18 +2907,18 @@ static const std::size_t value = sizeof...(Types); }; \end{codeblock} -\exitexample +\end{example} \pnum The result of \tcode{sizeof} and \tcode{sizeof...} is a constant of type \tcode{std::size_t}. -\enternote +\begin{note} \indextext{\idxcode{size_t}}% \indexlibrary{\idxcode{size_t}}% \tcode{std::size_t} is defined in the standard header \indextext{\idxhdr{cstddef}}% \tcode{}~(\ref{support.types}). -\exitnote +\end{note} \rSec2[expr.new]{New} @@ -2937,14 +2937,14 @@ thereof~(\ref{intro.object},~\ref{basic.types},~\ref{class.abstract}). It is \impldef{support for over-aligned types} whether over-aligned types are supported~(\ref{basic.align}). -\enternote +\begin{note} because references are not objects, references cannot be created by \grammarterm{new-expression}{s}. -\exitnote -\enternote +\end{note} +\begin{note} the \grammarterm{type-id} may be a cv-qualified type, in which case the object created by the \grammarterm{new-expression} has a cv-qualified type. -\exitnote +\end{note} \begin{bnf} \nontermdef{new-expression}\br @@ -2985,11 +2985,11 @@ \indextext{storage~duration!dynamic}% Entities created by a \grammarterm{new-expression} have dynamic storage duration~(\ref{basic.stc.dynamic}). -\enternote +\begin{note} \indextext{\idxcode{new}!scoping~and}% the lifetime of such an entity is not necessarily restricted to the scope in which it is created. -\exitnote +\end{note} If the entity is a non-array object, the \grammarterm{new-expression} returns a pointer to the object created. If it is an array, the \grammarterm{new-expression} returns a pointer to the initial element of @@ -3017,35 +3017,35 @@ T x(e); \end{codeblock} -\enterexample +\begin{example} \begin{codeblock} new auto(1); // allocated type is \tcode{int} auto x = new auto('a'); // allocated type is \tcode{char}, \tcode{x} is of type \tcode{char*} \end{codeblock} -\exitexample +\end{example} \pnum The \grammarterm{new-type-id} in a \grammarterm{new-expression} is the longest possible sequence of \grammarterm{new-declarator}{s}. -\enternote +\begin{note} this prevents ambiguities between the declarator operators \tcode{\&}, \tcode{\&\&}, \tcode{*}, and \tcode{[]} and their expression counterparts. -\exitnote -\enterexample +\end{note} +\begin{example} \begin{codeblock} new int * i; // syntax error: parsed as \tcode{(new int*) i}, not as \tcode{(new int)*i} \end{codeblock} The \tcode{*} is the pointer declarator and not the multiplication operator. -\exitexample +\end{example} \pnum -\enternote +\begin{note} \indextext{ambiguity!parentheses~and}% parentheses in a \grammarterm{new-type-id} of a \grammarterm{new-expression} can have surprising effects. -\enterexample +\begin{example} \begin{codeblock} new int(*[10])(); // error @@ -3067,8 +3067,8 @@ allocates an array of \tcode{10} pointers to functions (taking no argument and returning \tcode{int}). -\exitexample -\exitnote +\end{example} +\end{note} \pnum \indextext{array!\idxcode{new}}% @@ -3077,10 +3077,10 @@ \grammarterm{new-type-id} or \grammarterm{type-id} denotes an array type), the \grammarterm{new-expression} yields a pointer to the initial element (if any) of the array. -\enternote +\begin{note} both \tcode{new int} and \tcode{new int[10]} have type \tcode{int*} and the type of \tcode{new int[i][10]} is \tcode{int (*)[10]} -\exitnote +\end{note} The \grammarterm{attribute-specifier-seq} in a \grammarterm{noptr-new-declarator} appertains to the associated array type. @@ -3092,13 +3092,13 @@ \indextext{\idxcode{new}}% The \grammarterm{expression} in a \grammarterm{noptr-new-declarator}is implicitly converted to \tcode{std\colcol{}size_t}. -\enterexample +\begin{example} given the definition \tcode{int n = 42}, \tcode{new float[n][5]} is well-formed (because \tcode{n} is the \grammarterm{expression} of a \grammarterm{noptr-new-declarator}), but \tcode{new float[5][n]} is ill-formed (because \tcode{n} is not a constant expression). -\exitexample +\end{example} \pnum \indextext{function!allocation}% @@ -3167,14 +3167,14 @@ \tcode{operator new[]} and the deallocation function's name is \tcode{operator delete[]}. -\enternote +\begin{note} an implementation shall provide default definitions for the global allocation functions~(\ref{basic.stc.dynamic},~\ref{new.delete.single},~\ref{new.delete.array}). A \Cpp program can provide alternative definitions of these functions~(\ref{replacement.functions}) and/or class-specific versions~(\ref{class.free}). -\exitnote +\end{note} \pnum \indextext{operator!scope~resolution}% @@ -3216,7 +3216,7 @@ by \tcode{e1}. \end{itemize} -\enterexample +\begin{example} \begin{codeblock} void mergeable(int x) { // These allocations are safe for merging: @@ -3238,7 +3238,7 @@ } } \end{codeblock} -\exitexample +\end{example} \pnum When a \grammarterm{new-expression} calls an allocation function and that @@ -3254,14 +3254,14 @@ strictest fundamental alignment requirement~(\ref{basic.align}) of any object type whose size is no greater than the size of the array being created. -\enternote +\begin{note} \indextext{allocation!alignment~storage}% Because allocation functions are assumed to return pointers to storage that is appropriately aligned for objects of any type with fundamental alignment, this constraint on array allocation overhead permits the common idiom of allocating character arrays into which objects of other types will later be placed. -\exitnote +\end{note} \pnum When a \grammarterm{new-expression} calls an allocation function and that @@ -3286,7 +3286,7 @@ \defnx{placement \grammarterm{new-expression}}{placement~new-expression@placement \grammarterm{new-expression}}. \pnum -\enterexample +\begin{example} \begin{itemize} \item \tcode{new T} results in a call of \tcode{operator @@ -3310,10 +3310,10 @@ library function \tcode{operator new[](std::size_t, void*)} and other placement allocation functions. The amount of overhead may vary from one invocation of \tcode{new} to another. -\exitexample +\end{example} \pnum -\enternote +\begin{note} unless an allocation function has a non-throwing exception specification~(\ref{except.spec}), it indicates failure to allocate storage by throwing a @@ -3325,7 +3325,7 @@ has a non-throwing exception specification, it returns null to indicate failure to allocate storage and a non-null pointer otherwise. -\exitnote +\end{note} If the allocation function is a reserved placement allocation function~(\ref{new.delete.placement}) that returns null, the behavior is undefined. @@ -3335,13 +3335,13 @@ the \grammarterm{new-expression} shall be null. \pnum -\enternote +\begin{note} when the allocation function returns a value other than null, it must be a pointer to a block of storage in which space for the object has been reserved. The block of storage is assumed to be appropriately aligned and of the requested size. The address of the created object will not necessarily be the same as that of the block if the object is an array. -\exitnote +\end{note} \pnum \indextext{\idxcode{new}!array~of class~objects~and}% @@ -3356,8 +3356,8 @@ \begin{itemize} \item If the \grammarterm{new-initializer} is omitted, the object is -default-initialized~(\ref{dcl.init}). \enternote If no initialization -is performed, the object has an indeterminate value. \exitnote +default-initialized~(\ref{dcl.init}). \begin{note} If no initialization +is performed, the object has an indeterminate value. \end{note} \item Otherwise, the \grammarterm{new-initializer} is interpreted according to the initialization rules of~\ref{dcl.init} for direct-initialization. @@ -3398,10 +3398,10 @@ If no unambiguous matching deallocation function can be found, propagating the exception does not cause the object's memory to be freed. -\enternote +\begin{note} This is appropriate when the called allocation function does not allocate memory; otherwise, it is likely to result in a memory leak. -\exitnote +\end{note} \pnum If the \grammarterm{new-expression} begins with a unary \tcode{::} @@ -3426,7 +3426,7 @@ ill-formed. For a non-placement allocation function, the normal deallocation function lookup is used to find the matching deallocation function~(\ref{expr.delete}) -\enterexample +\begin{example} \begin{codeblock} struct S { @@ -3441,7 +3441,7 @@ // placement allocation function \end{codeblock} -\exitexample +\end{example} \pnum If a \grammarterm{new-expression} calls a deallocation function, it passes @@ -3511,17 +3511,17 @@ element of the array created by that \grammarterm{new-expression}. Zero-length arrays do not have a first element.} If not, the behavior is undefined. -\enternote +\begin{note} this means that the syntax of the \grammarterm{delete-expression} must match the type of the object allocated by \tcode{new}, not the syntax of the \grammarterm{new-expression}. -\exitnote -\enternote +\end{note} +\begin{note} a pointer to a \tcode{const} type can be the operand of a \grammarterm{delete-expression}; it is not necessary to cast away the constness~(\ref{expr.const.cast}) of the pointer expression before it is used as the operand of the \grammarterm{delete-expression}. -\exitnote +\end{note} \pnum \indextext{\idxcode{delete}!undefined}% @@ -3584,13 +3584,13 @@ Otherwise, it is unspecified whether the deallocation function will be called. -\enternote +\begin{note} The deallocation function is called regardless of whether the destructor for the object or some element of the array throws an exception. -\exitnote +\end{note} \pnum -\enternote +\begin{note} An implementation provides default definitions of the global deallocation functions \tcode{operator delete()} for non-arrays~(\ref{new.delete.single}) and @@ -3600,7 +3600,7 @@ program can provide alternative definitions of these functions~(\ref{replacement.functions}), and/or class-specific versions~(\ref{class.free}). -\exitnote +\end{note} \pnum When the keyword \tcode{delete} in a \grammarterm{delete-expression} is @@ -3688,11 +3688,11 @@ of type \tcode{T}. The result is an lvalue if \tcode{T} is an lvalue reference type or an rvalue reference to function type and an xvalue if \tcode{T} is an rvalue reference to object type; otherwise the result is a prvalue. -\enternote +\begin{note} if \tcode{T} is a non-class type that is cv-qualified, the \grammarterm{cv-qualifiers} are discarded when determining the type of the resulting prvalue; see Clause~\ref{expr}. -\exitnote +\end{note} \pnum An explicit type conversion can be expressed using functional @@ -3751,7 +3751,7 @@ conversion can be interpreted in more than one way as a \tcode{static_cast} followed by a \tcode{const_cast}, the conversion is ill-formed. -\enterexample +\begin{example} \begin{codeblock} struct A { }; @@ -3762,7 +3762,7 @@ return (A*)( p ); // ill-formed \tcode{static_cast} interpretation } \end{codeblock} -\exitexample +\end{example} \pnum \indextext{class!cast~to incomplete}% @@ -3773,12 +3773,12 @@ are incomplete, it is unspecified whether the \tcode{static_cast} or the \tcode{reinterpret_cast} interpretation is used, even if there is an inheritance relationship between the two classes. -\enternote +\begin{note} For example, if the classes were defined later in the translation unit, a multi-pass compiler would be permitted to interpret a cast between pointers to the classes as if the class types were complete at the point of the cast. -\exitnote% +\end{note}% \indextext{expression!cast|)} \rSec1[expr.mptr.oper]{Pointer-to-member operators} @@ -3829,7 +3829,7 @@ the \cvqual{cv-}qualifiers of the operands are combined to produce the \cvqual{cv-}qualifiers of the result, are the same as the rules for \tcode{E1.E2} given in~\ref{expr.ref}. -\enternote +\begin{note} it is not possible to use a pointer to member that refers to a \tcode{mutable} member to modify a \tcode{const} class object. For example, @@ -3846,14 +3846,14 @@ cs.*pm = 88; // ill-formed: \tcode{cs} is a \tcode{const} object } \end{codeblock} -\exitnote +\end{note} \pnum \indextext{function!pointer~to~member}% If the result of \tcode{.*} or \tcode{->*} is a function, then that result can be used only as the operand for the function call operator \tcode{()}. -\enterexample +\begin{example} \begin{codeblock} (ptr_to_obj->*ptr_to_mfct)(10); @@ -3861,7 +3861,7 @@ calls the member function denoted by \tcode{ptr_to_mfct} for the object pointed to by \tcode{ptr_to_obj}. -\exitexample +\end{example} In a \tcode{.*} expression whose object expression is an rvalue, the program is ill-formed if the second operand is a pointer to member function with \grammarterm{ref-qualifier} \tcode{\&}. @@ -4034,9 +4034,9 @@ For addition or subtraction, if the expressions \tcode{P} or \tcode{Q} have type ``pointer to \cv\ \tcode{T}'', where \tcode{T} and the array element type are not similar~(\ref{conv.qual}), the behavior is undefined. -\enternote In particular, a pointer to a base class cannot be used for +\begin{note} In particular, a pointer to a base class cannot be used for pointer arithmetic when the array contains objects of a derived class type. -\exitnote +\end{note} \pnum If the value 0 is added to or subtracted from a pointer value, the @@ -4100,10 +4100,10 @@ \pnum The relational operators group left-to-right. -\enterexample +\begin{example} \tcode{a z; z = { 1,2 }; // meaning \tcode{z.operator=(\{1,2\})} @@ -4749,7 +4749,7 @@ a = b = { 1 }; // meaning \tcode{a=b=1;} a = { 1 } = b; // syntax error \end{codeblock} -\exitexample +\end{example} \rSec1[expr.comma]{Comma operator}% \indextext{expression!comma}% @@ -4786,11 +4786,11 @@ the result is that temporary. \pnum -In contexts where comma is given a special meaning, \enterexample in +In contexts where comma is given a special meaning, \begin{example} in lists of arguments to functions~(\ref{expr.call}) and lists of -initializers~(\ref{dcl.init}) \exitexample the comma operator as +initializers~(\ref{dcl.init}) \end{example} the comma operator as described in Clause~\ref{expr} can appear only in parentheses. -\enterexample +\begin{example} \begin{codeblock} f(a, (t=3, t+2), c); @@ -4798,7 +4798,7 @@ has three arguments, the second of which has the value \tcode{5}. -\exitexample +\end{example} \rSec1[expr.const]{Constant expressions}% \indextext{expression!constant} @@ -4809,8 +4809,8 @@ semantics depending on whether or not an expression satisfies these requirements. Expressions that satisfy these requirements are called \indexdefn{expression!constant}% -\defn{constant expression}{s}. \enternote Constant expressions can be evaluated -during translation.\exitnote +\defn{constant expression}{s}. \begin{note} Constant expressions can be evaluated +during translation.\end{note} \begin{bnf} \nontermdef{constant-expression}\br @@ -4834,8 +4834,8 @@ a \tcode{constexpr} constructor for a literal class, a \tcode{constexpr} function, or an implicit invocation of a trivial destructor~(\ref{class.dtor}) -\enternote Overload resolution~(\ref{over.match}) -is applied as usual \exitnote; +\begin{note} Overload resolution~(\ref{over.match}) +is applied as usual \end{note}; \item an invocation of an undefined \tcode{constexpr} function or an @@ -4854,11 +4854,11 @@ \item an operation that would have undefined behavior as specified in Clauses~\ref{intro} through~\ref{cpp} -of this International Standard \enternote including, +of this International Standard \begin{note} including, for example, signed integer overflow~(Clause \ref{expr}), certain pointer arithmetic~(\ref{expr.add}), division by zero~(\ref{expr.mul}), or certain shift operations~(\ref{expr.shift}) -\exitnote; +\end{note}; \item an lvalue-to-rvalue conversion~(\ref{conv.lval}) unless @@ -4909,7 +4909,7 @@ automatic storage duration defined outside that \grammarterm{lambda-expression}, where the reference would be an odr-use~(\ref{basic.def.odr}, \ref{expr.prim.lambda}); -\enterexample +\begin{example} \begin{codeblock} void g() { const int n = 0; @@ -4919,15 +4919,15 @@ }; } \end{codeblock} -\exitexample -\enternote +\end{example} +\begin{note} If the odr-use occurs in an invocation of a function call operator of a closure type, it no longer refers to \tcode{this} or to an enclosing automatic variable due to the transformation~(\ref{expr.prim.lambda}) of the \grammarterm{id-expression} into an access of the corresponding data member. -\enterexample +\begin{example} \begin{codeblock} auto monad = [](auto v) { return [=] { return v; }; }; auto bind = [](auto m) { @@ -4937,8 +4937,8 @@ // OK to have captures to automatic objects created during constant expression evaluation. static_assert(bind(monad(2))(monad)() == monad(2)()); \end{codeblock} -\exitexample -\exitnote +\end{example} +\end{note} \item a conversion from type \cv{} \tcode{void *} to a pointer-to-object type; @@ -4983,7 +4983,7 @@ International Standard, it is unspecified whether \tcode{e} is a core constant expression. -\enterexample +\begin{example} \begin{codeblock} int x; // not constant struct A { @@ -5025,18 +5025,18 @@ // \tcode{h(1)} is a core constant expression because // the lifetime of \tcode{k} begins inside \tcode{h(1)} \end{codeblock} -\exitexample +\end{example} \pnum An \defnx{integral constant expression}{expression!integral~constant} is an expression of integral or unscoped enumeration type, implicitly converted to a prvalue, where the converted expression is a core constant expression. -\enternote +\begin{note} Such expressions may be used as bit-field lengths~(\ref{class.bit}), as enumerator initializers if the underlying type is not fixed~(\ref{dcl.enum}), and as alignments~(\ref{dcl.align}). -\exitnote +\end{note} \pnum A \defnx{converted constant expression}{expression!converted~constant} @@ -5059,14 +5059,14 @@ \end{itemize} and where the reference binding (if any) binds directly. -\enternote +\begin{note} such expressions may be used in \tcode{new} expressions~(\ref{expr.new}), as case expressions~(\ref{stmt.switch}), as enumerator initializers if the underlying type is fixed~(\ref{dcl.enum}), as array bounds~(\ref{dcl.array}), and as non-type template arguments~(\ref{temp.arg}). -\exitnote +\end{note} \indextext{contextually converted constant expression of type \tcode{bool}|see{conversion, contextual}}% \indextext{conversion!contextual to constant expression of type \tcode{bool}}% A \term{contextually converted constant expression of type \tcode{bool}} is @@ -5107,13 +5107,13 @@ function. \pnum -\enternote Since this International Standard +\begin{note} Since this International Standard imposes no restrictions on the accuracy of floating-point operations, it is unspecified whether the evaluation of a floating-point expression during translation yields the same result as the evaluation of the same expression (or the same operations on the same values) during program execution.\footnote{Nonetheless, implementations are encouraged to provide consistent results, irrespective of whether the evaluation was performed during translation and/or during program -execution.} \enterexample +execution.} \begin{example} \begin{codeblock} bool f() { @@ -5123,14 +5123,14 @@ } \end{codeblock} It is unspecified whether the value of \tcode{f()} will be \tcode{true} or \tcode{false}. -\exitexample \exitnote +\end{example} \end{note} \pnum If an expression of literal class type is used in a context where an integral constant expression is required, then that expression is contextually implicitly converted (Clause~\ref{conv}) to an integral or unscoped enumeration type -and the selected conversion function shall be \tcode{constexpr}. \enterexample +and the selected conversion function shall be \tcode{constexpr}. \begin{example} \begin{codeblock} struct A { constexpr A(int i) : val(i) { } @@ -5144,5 +5144,5 @@ X x; // OK: unique conversion to \tcode{int} int ary[a]; // error: ambiguous conversion \end{codeblock} -\exitexample% +\end{example}% \indextext{expression|)} diff --git a/source/future.tex b/source/future.tex index f22c53cbff..2e30cbced3 100644 --- a/source/future.tex +++ b/source/future.tex @@ -94,7 +94,7 @@ \indextext{namespace}% \pnum -\enterexample +\begin{example} The header \indexlibrary{\idxhdr{cstdlib}}% \indexlibrary{\idxhdr{stdlib.h}}% @@ -108,7 +108,7 @@ the global namespace, much as in the C Standard. It may also provide these names within the namespace \tcode{std}. -\exitexample +\end{example} \rSec1[depr.str.strstreams]{\tcode{char*} streams} @@ -177,7 +177,7 @@ The array object has several attributes. \pnum -\enternote +\begin{note} For the sake of exposition, these are represented as elements of a bitmask type (indicated here as \tcode{T1}) called \tcode{strstate}. The elements are: @@ -197,10 +197,10 @@ \tcode{frozen}, set when the program has requested that the array object not be altered, reallocated, or freed. \end{itemize} -\exitnote +\end{note} \pnum -\enternote +\begin{note} For the sake of exposition, the maintained data is presented here as: \begin{itemize} \item @@ -216,7 +216,7 @@ \tcode{void (*pfree)(void*)}, points to the function to call to free a dynamic array object. \end{itemize} -\exitnote +\end{note} \pnum Each object of class @@ -1207,7 +1207,7 @@ \begin{itemdescr} \pnum \returns The current \tcode{unexpected_handler}. -\enternote This may be a null pointer value. \exitnote +\begin{note} This may be a null pointer value. \end{note} \end{itemdescr} \rSec2[unexpected]{\tcode{unexpected}} @@ -1230,8 +1230,8 @@ \tcode{unexpected_handler} function will be called if an exception is active during a call to \tcode{set_unexpected}. Otherwise calls the current \tcode{unexpected_handler} function. -\enternote A default \tcode{unexpected_handler} is always considered a callable handler in -this context. \exitnote +\begin{note} A default \tcode{unexpected_handler} is always considered a callable handler in +this context. \end{note} \end{itemdescr} \rSec1[depr.uncaught]{\tcode{uncaught_exception}} diff --git a/source/intro.tex b/source/intro.tex index 28f1019620..d9fefb64f1 100644 --- a/source/intro.tex +++ b/source/intro.tex @@ -159,8 +159,8 @@ \indexdefn{behavior!conditionally-supported}% \definition{conditionally-supported}{defns.cond.supp} program construct that an implementation is not required to support\\ -\enternote Each implementation documents all conditionally-supported -constructs that it does not support.\exitnote +\begin{note} Each implementation documents all conditionally-supported +constructs that it does not support.\end{note} \indexdefn{message!diagnostic}% \definition{diagnostic message}{defns.diagnostic} @@ -171,13 +171,13 @@ \definition{dynamic type}{defns.dynamic.type} \defncontext{glvalue} type of the most derived object~(\ref{intro.object}) to which the glvalue refers\\ -\enterexample +\begin{example} if a pointer~(\ref{dcl.ptr}) \tcode{p} whose static type is ``pointer to class \tcode{B}'' is pointing to an object of class \tcode{D}, derived from \tcode{B} (Clause~\ref{class.derived}), the dynamic type of the expression \tcode{*p} is ``\tcode{D}''. References~(\ref{dcl.ref}) are treated similarly. -\exitexample +\end{example} \indexdefn{type!dynamic}% \definition{dynamic type}{defns.dynamic.type.prvalue} @@ -205,9 +205,9 @@ \definition{multibyte character}{defns.multibyte} sequence of one or more bytes representing a member of the extended character set of either the source or the execution environment\\ -\enternote The +\begin{note} The extended character set is a superset of the basic character -set~(\ref{lex.charset}).\exitnote +set~(\ref{lex.charset}).\end{note} \indexdefn{parameter}% \indexdefn{parameter!function}% @@ -232,8 +232,8 @@ \indexdefn{signature}% \definition{signature}{defns.signature} \defncontext{function} name, parameter type list~(\ref{dcl.fct}), and enclosing namespace (if any)\\ -\enternote Signatures are used as a basis for -name mangling and linking.\exitnote +\begin{note} Signatures are used as a basis for +name mangling and linking.\end{note} \indexdefn{signature}% \definition{signature}{defns.signature.templ} @@ -266,16 +266,16 @@ \definition{static type}{defns.static.type} type of an expression~(\ref{basic.types}) resulting from analysis of the program without considering execution semantics\\ -\enternote The +\begin{note} The static type of an expression depends only on the form of the program in which the expression appears, and does not change while the program is -executing. \exitnote +executing. \end{note} \indexdefn{behavior!undefined}% \definition{undefined behavior}{defns.undefined} behavior for which this International Standard imposes no requirements\\ -\enternote Undefined behavior may be expected when +\begin{note} Undefined behavior may be expected when this International Standard omits any explicit definition of behavior or when a program uses an erroneous construct or erroneous data. Permissible undefined behavior ranges @@ -285,16 +285,16 @@ diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). Many erroneous program constructs do not engender undefined behavior; they are required to be diagnosed. -\exitnote +\end{note} \indexdefn{behavior!unspecified}% \definition{unspecified behavior}{defns.unspecified} behavior, for a well-formed program construct and correct data, that depends on the implementation\\ -\enternote The implementation is not required to +\begin{note} The implementation is not required to document which behavior occurs. The range of possible behaviors is usually delineated by this International Standard. -\exitnote +\end{note} \indexdefn{program!well-formed}% \definition{well-formed program}{defns.well.formed} @@ -424,8 +424,8 @@ \pnum Throughout this International Standard, each example is introduced by -``\enterexample'' and terminated by ``\exitexample''. Each note is -introduced by ``\enternote'' and terminated by ``\exitnote''. Examples +``\begin{example}'' and terminated by ``\end{example}''. Each note is +introduced by ``\begin{note}'' and terminated by ``\end{note}''. Examples and notes may be nested.% \indextext{standard!structure of|)} @@ -483,30 +483,30 @@ contiguous bytes. Every byte has a unique address. \pnum -\enternote The representation of types is described -in~\ref{basic.types}. \exitnote +\begin{note} The representation of types is described +in~\ref{basic.types}. \end{note} \pnum A \defn{memory location} is either an object of scalar type or a maximal -sequence of adjacent bit-fields all having non-zero width. \enternote Various +sequence of adjacent bit-fields all having non-zero width. \begin{note} Various features of the language, such as references and virtual functions, might involve additional memory locations that are not accessible to programs but are -managed by the implementation. \exitnote Two or more threads of +managed by the implementation. \end{note} Two or more threads of execution~(\ref{intro.multithread}) can access separate memory locations without interfering with each other. \pnum -\enternote Thus a bit-field and an adjacent non-bit-field are in separate memory +\begin{note} Thus a bit-field and an adjacent non-bit-field are in separate memory locations, and therefore can be concurrently updated by two threads of execution without interference. The same applies to two bit-fields, if one is declared inside a nested struct declaration and the other is not, or if the two are separated by a zero-length bit-field declaration, or if they are separated by a non-bit-field declaration. It is not safe to concurrently update two bit-fields in the same struct if all fields between them are also bit-fields of non-zero -width. \exitnote +width. \end{note} \pnum -\enterexample A structure declared as +\begin{example} A structure declared as \begin{codeblock} struct { @@ -524,7 +524,7 @@ modified concurrently without interfering with each other. The bit-fields \tcode{b} and \tcode{c} together constitute the fourth memory location. The bit-fields \tcode{b} and \tcode{c} cannot be concurrently modified, but -\tcode{b} and \tcode{a}, for example, can be. \exitexample% +\tcode{b} and \tcode{a}, for example, can be. \end{example}% \indextext{memory model|)} \rSec1[intro.object]{The \Cpp object model} @@ -534,8 +534,8 @@ \indextext{object}% The constructs in a \Cpp program create, destroy, refer to, access, and manipulate objects. An \defn{object} is a region of storage. -\enternote A function is not an object, regardless of whether or not it -occupies storage in the way that objects do. \exitnote An object is +\begin{note} A function is not an object, regardless of whether or not it +occupies storage in the way that objects do. \end{note} An object is created by a \grammarterm{definition}~(\ref{basic.def}), by a \grammarterm{new-expression}~(\ref{expr.new}) or by the implementation~(\ref{class.temporary}) when needed. The properties of an @@ -607,19 +607,19 @@ not store an object at all if the program cannot observe the difference~(\ref{intro.execution}).} -\enterexample +\begin{example} \begin{codeblock} static const char test1 = 'x'; static const char test2 = 'x'; const bool b = &test1 != &test2; // always true \end{codeblock} -\exitexample +\end{example} \pnum -\enternote +\begin{note} \Cpp provides a variety of fundamental types and several ways of composing new types from existing types~(\ref{basic.types}). -\exitnote% +\end{note}% \indextext{object model|)} \rSec1[intro.execution]{Program execution} @@ -674,8 +674,8 @@ Certain other operations are described in this International Standard as undefined (for example, the effect of attempting to modify a \tcode{const} object). -\enternote This International Standard imposes no requirements on the -behavior of programs that contain undefined behavior. \exitnote +\begin{note} This International Standard imposes no requirements on the +behavior of programs that contain undefined behavior. \end{note} \indextext{program!well-formed}% \indextext{behavior!observable}% @@ -696,9 +696,9 @@ If a signal handler is executed as a result of a call to the \tcode{raise} function, then the execution of the handler is sequenced after the invocation of the \tcode{raise} function and before its return. -\enternote When a signal is received for another reason, the execution of the +\begin{note} When a signal is received for another reason, the execution of the signal handler is usually unsequenced with respect to the rest of the program. -\exitnote +\end{note} \pnum An instance of each object with automatic storage @@ -731,13 +731,13 @@ These collectively are referred to as the \defnx{observable behavior}{behavior!observable} of the program. -\enternote More stringent correspondences between abstract and actual -semantics may be defined by each implementation. \exitnote +\begin{note} More stringent correspondences between abstract and actual +semantics may be defined by each implementation. \end{note} \pnum \indextext{operator!precedence of}% \indextext{expression!order of evaluation of}% -\enternote Operators can be regrouped according to the usual +\begin{note} Operators can be regrouped according to the usual mathematical rules only where the operators really are associative or commutative.\footnote{Overloaded operators are never assumed to be associative or commutative. } @@ -777,17 +777,17 @@ overflows do not produce an exception and in which the results of overflows are reversible, the above expression statement can be rewritten by the implementation in any of the above ways because the -same result will occur. \exitnote +same result will occur. \end{note} \pnum \indextext{full-expression}% A \defn{full-expression} is an expression that is not a subexpression of another expression. -\enternote +\begin{note} in some contexts, such as unevaluated operands, a syntactic subexpression is considered a full-expression (Clause~\ref{expr}). -\exitnote +\end{note} If a language construct is defined to produce an implicit call of a function, a use of the language construct is considered to be an expression for the purposes of this @@ -798,7 +798,7 @@ expression appears are also considered to be part of the full-expression. -\enterexample +\begin{example} \begin{codeblock} struct S { S(int i): I(i) { } @@ -817,15 +817,15 @@ { } } \end{codeblock} -\exitexample +\end{example} \pnum -\enternote The evaluation of a full-expression can include the +\begin{note} The evaluation of a full-expression can include the evaluation of subexpressions that are not lexically part of the full-expression. For example, subexpressions involved in evaluating default arguments~(\ref{dcl.fct.default}) are considered to be created in the expression that calls the function, not the expression -that defines the default argument. \exitnote +that defines the default argument. \end{note} \pnum \indextext{value computation|(}% @@ -853,12 +853,12 @@ then the execution of \term{A} shall precede the execution of \term{B}. If \term{A} is not sequenced before \term{B} and \term{B} is not sequenced before \term{A}, then \term{A} and -\term{B} are \defn{unsequenced}. \enternote The execution of unsequenced -evaluations can overlap. \exitnote Evaluations \term{A} and \term{B} are +\term{B} are \defn{unsequenced}. \begin{note} The execution of unsequenced +evaluations can overlap. \end{note} Evaluations \term{A} and \term{B} are \defn{indeterminately sequenced} when either \term{A} is sequenced before \term{B} or \term{B} is sequenced before \term{A}, but it is unspecified which. -\enternote Indeterminately sequenced evaluations cannot overlap, but either -could be executed first. \exitnote +\begin{note} Indeterminately sequenced evaluations cannot overlap, but either +could be executed first. \end{note} \pnum Every @@ -875,11 +875,11 @@ \pnum \indextext{evaluation!unspecified order~of}% Except where noted, evaluations of operands of individual operators and -of subexpressions of individual expressions are unsequenced. \enternote +of subexpressions of individual expressions are unsequenced. \begin{note} In an expression that is evaluated more than once during the execution of a program, unsequenced and indeterminately sequenced evaluations of its subexpressions need not be performed consistently in different -evaluations. \exitnote The value computations of the operands of an +evaluations. \end{note} The value computations of the operands of an operator are sequenced before the value computation of the result of the operator. If a \indextext{side effects}% @@ -888,12 +888,12 @@ a value computation using the value of any object in the same memory location, and they are not potentially concurrent~(\ref{intro.multithread}), the behavior is undefined. -\enternote +\begin{note} The next section imposes similar, but more complex restrictions on potentially concurrent computations. -\exitnote +\end{note} -\enterexample +\begin{example} \begin{codeblock} void f(int, int); @@ -907,7 +907,7 @@ f(i = -1, i = -1); // the behavior is undefined } \end{codeblock} -\exitexample +\end{example} When calling a function (whether or not the function is inline), every \indextext{value computation}% @@ -916,10 +916,10 @@ side effect associated with any argument expression, or with the postfix expression designating the called function, is sequenced before execution of every expression or statement -in the body of the called function. \enternote +in the body of the called function. \begin{note} Value computations and side effects associated with different argument expressions are -unsequenced. \exitnote +unsequenced. \end{note} For each function invocation \term{F}, for every evaluation \term{A} that occurs within \term{F} and every evaluation \term{B} that does not occur within \term{F} but @@ -928,19 +928,19 @@ \term{B} is sequenced before \term{A}. \footnote{In other words, function executions do not interleave with each other.} -\enternote +\begin{note} If \term{A} and \term{B} would not otherwise be sequenced then they are indeterminately sequenced. -\exitnote +\end{note} Several contexts in \Cpp cause evaluation of a function call, even though no corresponding function call syntax appears in the translation unit. -\enterexample +\begin{example} Evaluation of a \grammarterm{new-expression} invokes one or more allocation and constructor functions; see~\ref{expr.new}. For another example, invocation of a conversion function~(\ref{class.conv.fct}) can arise in contexts in which no function call syntax appears. -\exitexample +\end{example} The sequencing constraints on the execution of the called function (as described above) are features of the function calls as evaluated, whatever the syntax of the expression that calls the function might be.% @@ -955,9 +955,9 @@ A \defn{thread of execution} (also known as a \defn{thread}) is a single flow of control within a program, including the initial invocation of a specific top-level function, and recursively including every function invocation -subsequently executed by the thread. \enternote When one thread creates another, +subsequently executed by the thread. \begin{note} When one thread creates another, the initial call to the top-level function of the new thread is executed by the -new thread, not by the creating thread. \exitnote Every thread in a program can +new thread, not by the creating thread. \end{note} Every thread in a program can potentially access every object and function in a program.\footnote{An object with automatic or thread storage duration~(\ref{basic.stc}) is associated with one specific thread, and can be accessed by a different thread only indirectly @@ -965,10 +965,10 @@ implementation, a \Cpp program can have more than one thread running concurrently. The execution of each thread proceeds as defined by the remainder of this standard. The execution of the entire program consists of an execution -of all of its threads. \enternote Usually the execution can be viewed as an +of all of its threads. \begin{note} Usually the execution can be viewed as an interleaving of all its threads. However, some kinds of atomic operations, for example, allow executions inconsistent with a simple interleaving, as described -below. \exitnote Under a freestanding implementation, it is \impldef{number of +below. \end{note} Under a freestanding implementation, it is \impldef{number of threads in a program under a freestanding implementation} whether a program can have more than one thread of execution. @@ -980,10 +980,10 @@ \pnum Implementations should ensure that all unblocked threads eventually make -progress. \enternote Standard library functions may silently block on I/O or +progress. \begin{note} Standard library functions may silently block on I/O or locks. Factors in the execution environment, including externally-imposed thread priorities, may prevent an implementation from making certain guarantees of -forward progress. \exitnote +forward progress. \end{note} \pnum Executions of atomic functions @@ -994,18 +994,18 @@ \item If there is only one unblocked thread, a lock-free execution in that thread shall complete. - \enternote + \begin{note} Concurrently executing threads may prevent progress of a lock-free execution. For example, this situation can occur with load-locked store-conditional implementations. This property is sometimes termed obstruction-free. - \exitnote + \end{note} \item When one or more lock-free executions run concurrently, at least one should complete. - \enternote + \begin{note} It is difficult for some implementations to provide absolute guarantees to this effect, since repeated and particularly inopportune interference @@ -1022,17 +1022,17 @@ can therefore safely be ignored by programmers. Outside this International Standard, this property is sometimes termed lock-free. - \exitnote + \end{note} \end{itemize} \pnum The value of an object visible to a thread \term{T} at a particular point is the initial value of the object, a value assigned to the object by \term{T}, or a value assigned to the object by another thread, according to the rules below. -\enternote In some cases, there may instead be undefined behavior. Much of this +\begin{note} In some cases, there may instead be undefined behavior. Much of this section is motivated by the desire to support atomic operations with explicit and detailed visibility constraints. However, it also implicitly supports a -simpler view for more restricted programs. \exitnote +simpler view for more restricted programs. \end{note} \pnum Two expression evaluations \defn{conflict} if one of them modifies a memory @@ -1050,7 +1050,7 @@ acquire fence, a release fence, or both an acquire and release fence. In addition, there are relaxed atomic operations, which are not synchronization operations, and atomic read-modify-write operations, which have special -characteristics. \enternote For example, a call that acquires a mutex will +characteristics. \begin{note} For example, a call that acquires a mutex will perform an acquire operation on the locations comprising the mutex. Correspondingly, a call that releases the same mutex will perform a release operation on those same locations. Informally, performing a release operation on @@ -1060,7 +1060,7 @@ to other threads that later perform a consume or an acquire operation on \term{A}. ``Relaxed'' atomic operations are not synchronization operations even though, like synchronization operations, they cannot contribute to data races. -\exitnote +\end{note} \pnum All modifications to a particular atomic object \term{M} occur in some @@ -1068,12 +1068,12 @@ \term{A} and \term{B} are modifications of an atomic object \term{M} and \term{A} happens before (as defined below) \term{B}, then \term{A} shall precede \term{B} in the modification order of \term{M}, which is defined below. -\enternote This states that the modification orders must respect the ``happens -before'' relationship. \exitnote \enternote There is a separate order for each +\begin{note} This states that the modification orders must respect the ``happens +before'' relationship. \end{note} \begin{note} There is a separate order for each atomic object. There is no requirement that these can be combined into a single total order for all objects. In general this will be impossible since different threads may observe modifications to different objects in inconsistent orders. -\exitnote +\end{note} \pnum A \defn{release sequence} headed by a release operation \term{A} on an atomic object @@ -1092,13 +1092,13 @@ Certain library calls \defn{synchronize with} other library calls performed by another thread. For example, an atomic store-release synchronizes with a load-acquire that takes its value from the store~(\ref{atomics.order}). -\enternote Except in the specified cases, reading a later value does not +\begin{note} Except in the specified cases, reading a later value does not necessarily ensure visibility as described below. Such a requirement would -sometimes interfere with efficient implementation. \exitnote \enternote The +sometimes interfere with efficient implementation. \end{note} \begin{note} The specifications of the synchronization operations define when one reads the value written by another. For atomic objects, the definition is clear. All operations on a given mutex occur in a single total order. Each mutex acquisition ``reads -the value written'' by the last mutex release. \exitnote +the value written'' by the last mutex release. \end{note} \pnum An evaluation \term{A} \defn{carries a dependency} to an evaluation \term{B} if @@ -1136,8 +1136,8 @@ \end{itemize} -\enternote ``Carries a dependency to'' is a subset of ``is sequenced before'', -and is similarly strictly intra-thread. \exitnote +\begin{note} ``Carries a dependency to'' is a subset of ``is sequenced before'', +and is similarly strictly intra-thread. \end{note} \pnum An evaluation \term{A} is \defn{dependency-ordered before} an evaluation @@ -1156,9 +1156,9 @@ \term{X} carries a dependency to \term{B}. \end{itemize} -\enternote The relation ``is dependency-ordered before'' is analogous to +\begin{note} The relation ``is dependency-ordered before'' is analogous to ``synchronizes with'', but uses release/consume in place of release/acquire. -\exitnote +\end{note} \pnum An evaluation \term{A} \defn{inter-thread happens before} an evaluation \term{B} @@ -1190,7 +1190,7 @@ \end{itemize} \end{itemize} -\enternote The ``inter-thread happens before'' relation describes arbitrary +\begin{note} The ``inter-thread happens before'' relation describes arbitrary concatenations of ``sequenced before'', ``synchronizes with'' and ``dependency-ordered before'' relationships, with two exceptions. The first exception is that a concatenation is not permitted to end with @@ -1204,7 +1204,7 @@ permitted to consist entirely of ``sequenced before''. The reasons for this limitation are (1) to permit ``inter-thread happens before'' to be transitively closed and (2) the ``happens before'' relation, defined below, provides for -relationships consisting entirely of ``sequenced before''. \exitnote +relationships consisting entirely of ``sequenced before''. \end{note} \pnum An evaluation \term{A} \defn{happens before} an evaluation \term{B} @@ -1216,8 +1216,8 @@ \end{itemize} The implementation shall ensure that no program execution demonstrates a cycle -in the ``happens before'' relation. \enternote This cycle would otherwise be -possible only through the use of consume operations. \exitnote +in the ``happens before'' relation. \begin{note} This cycle would otherwise be +possible only through the use of consume operations. \end{note} \pnum A \defnx{visible side effect}{side effects!visible} \term{A} on a scalar object or bit-field \term{M} @@ -1236,13 +1236,13 @@ evaluation \term{B}, shall be the value stored by the \indextext{side effects!visible}% visible side effect -\term{A}. \enternote If there is ambiguity about which side effect to a +\term{A}. \begin{note} If there is ambiguity about which side effect to a non-atomic object or bit-field is visible, then the behavior is either -unspecified or undefined. \exitnote \enternote This states that operations on +unspecified or undefined. \end{note} \begin{note} This states that operations on ordinary objects are not visibly reordered. This is not actually detectable without data races, but it is necessary to ensure that data races, as defined below, and with suitable restrictions on the use of atomics, correspond to data -races in a simple interleaved (sequentially consistent) execution. \exitnote +races in a simple interleaved (sequentially consistent) execution. \end{note} \pnum The value of an @@ -1250,16 +1250,16 @@ stored by some side effect \term{A} that modifies \term{M}, where \term{B} does not happen before \term{A}. -\enternote +\begin{note} The set of such side effects is also restricted by the rest of the rules described here, and in particular, by the coherence requirements below. -\exitnote +\end{note} \pnum If an operation \term{A} that modifies an atomic object \term{M} happens before an operation \term{B} that modifies \term{M}, then \term{A} shall be earlier -than \term{B} in the modification order of \term{M}. \enternote This requirement -is known as write-write coherence. \exitnote +than \term{B} in the modification order of \term{M}. \begin{note} This requirement +is known as write-write coherence. \end{note} \pnum If a @@ -1271,7 +1271,7 @@ \indextext{side effects}% side effect \term{Y} on \term{M}, where \term{Y} follows \term{X} in the modification order of \term{M}. -\enternote This requirement is known as read-read coherence. \exitnote +\begin{note} This requirement is known as read-read coherence. \end{note} \pnum If a @@ -1279,8 +1279,8 @@ value computation \term{A} of an atomic object \term{M} happens before an operation \term{B} that modifies \term{M}, then \term{A} shall take its value from a side effect \term{X} on \term{M}, where \term{X} precedes \term{B} in the -modification order of \term{M}. \enternote This requirement is known as -read-write coherence. \exitnote +modification order of \term{M}. \begin{note} This requirement is known as +read-write coherence. \end{note} \pnum If a @@ -1290,23 +1290,23 @@ value from \term{X} or from a \indextext{side effects}% side effect \term{Y} that follows \term{X} in the -modification order of \term{M}. \enternote This requirement is known as -write-read coherence. \exitnote +modification order of \term{M}. \begin{note} This requirement is known as +write-read coherence. \end{note} \pnum -\enternote The four preceding coherence requirements effectively disallow +\begin{note} The four preceding coherence requirements effectively disallow compiler reordering of atomic operations to a single object, even if both operations are relaxed loads. This effectively makes the cache coherence guarantee provided by most hardware available to \Cpp atomic operations. -\exitnote +\end{note} \pnum -\enternote The value observed by a load of an atomic depends on the ``happens +\begin{note} The value observed by a load of an atomic depends on the ``happens before'' relation, which depends on the values observed by loads of atomics. The intended reading is that there must exist an association of atomic loads with modifications they observe that, together with suitably chosen modification orders and the ``happens before'' relation derived -as described above, satisfy the resulting constraints as imposed here. \exitnote +as described above, satisfy the resulting constraints as imposed here. \end{note} \pnum \indextext{potentially~concurrent}% @@ -1321,7 +1321,7 @@ and neither happens before the other, except for the special case for signal handlers described below. Any such data race results in undefined -behavior. \enternote It can be shown that programs that correctly use mutexes +behavior. \begin{note} It can be shown that programs that correctly use mutexes and \tcode{memory_order_seq_cst} operations to prevent all data races and use no other synchronization operations behave as if the operations executed by their constituent threads were simply interleaved, with each @@ -1335,7 +1335,7 @@ programs cannot observe most program transformations that do not change single-threaded program semantics. In fact, most single-threaded program transformations continue to be allowed, since any program that behaves -differently as a result must perform an undefined operation. \exitnote +differently as a result must perform an undefined operation. \end{note} \pnum Two accesses to the same object of type \tcode{volatile sig_atomic_t} do not @@ -1350,7 +1350,7 @@ in \placeholder{B}. \pnum -\enternote Compiler transformations that introduce assignments to a potentially +\begin{note} Compiler transformations that introduce assignments to a potentially shared memory location that would not be modified by the abstract machine are generally precluded by this standard, since such an assignment might overwrite another assignment by a different thread in cases in which an abstract machine @@ -1358,16 +1358,16 @@ of data member assignment that overwrite adjacent members in separate memory locations. Reordering of atomic loads in cases in which the atomics in question may alias is also generally precluded, since this may violate the coherence -rules. \exitnote +rules. \end{note} \pnum -\enternote Transformations that introduce a speculative read of a potentially +\begin{note} Transformations that introduce a speculative read of a potentially shared memory location may not preserve the semantics of the \Cpp program as defined in this standard, since they potentially introduce a data race. However, they are typically valid in the context of an optimizing compiler that targets a specific machine with well-defined semantics for data races. They would be invalid for a hypothetical machine that is not tolerant of races or provides -hardware race detection. \exitnote +hardware race detection. \end{note} \pnum The implementation may assume that any thread will eventually do one of the @@ -1387,8 +1387,8 @@ perform a synchronization operation or an atomic operation. \end{itemize} -\enternote This is intended to allow compiler transformations such as removal of -empty loops, even when termination cannot be proven. \exitnote +\begin{note} This is intended to allow compiler transformations such as removal of +empty loops, even when termination cannot be proven. \end{note} \pnum An implementation should ensure that the last value (in modification order) diff --git a/source/iostreams.tex b/source/iostreams.tex index 30fd11398d..459a5455df 100644 --- a/source/iostreams.tex +++ b/source/iostreams.tex @@ -103,7 +103,7 @@ Concurrent access to a stream object (\ref{string.streams},~\ref{file.streams}), stream buffer object~(\ref{stream.buffers}), or C Library stream~(\ref{c.files}) by multiple threads may result in a data race~(\ref{intro.multithread}) unless otherwise specified~(\ref{iostream.objects}). -\enternote Data races result in undefined behavior~(\ref{intro.multithread}). \exitnote +\begin{note} Data races result in undefined behavior~(\ref{intro.multithread}). \end{note} \pnum If one thread makes a library call \textit{a} that writes a value to a stream @@ -255,7 +255,7 @@ multiple occurrences of default arguments.} \pnum -\enternote +\begin{note} The class template specialization \tcode{basic_ios} @@ -355,7 +355,7 @@ pos_type; } \end{codeblock} -\exitnote +\end{note} \rSec1[iostream.objects]{Standard iostream objects} @@ -427,7 +427,7 @@ as specified in Amendment 1 of the ISO C standard. \pnum -Concurrent access to a synchronized~(\ref{ios.members.static}) standard iostream object's formatted and unformatted input~(\ref{istream}) and output~(\ref{ostream}) functions or a standard C stream by multiple threads shall not result in a data race~(\ref{intro.multithread}). \enternote Users must still synchronize concurrent use of these objects and streams by multiple threads if they wish to avoid interleaved characters. \exitnote +Concurrent access to a synchronized~(\ref{ios.members.static}) standard iostream object's formatted and unformatted input~(\ref{istream}) and output~(\ref{ostream}) functions or a standard C stream by multiple threads shall not result in a data race~(\ref{intro.multithread}). \begin{note} Users must still synchronize concurrent use of these objects and streams by multiple threads if they wish to avoid interleaved characters. \end{note} \rSec2[narrow.stream.objects]{Narrow stream objects} @@ -847,7 +847,7 @@ \end{itemize} \pnum -\enternote +\begin{note} For the sake of exposition, the maintained data is presented here as: \begin{itemize} \item @@ -866,8 +866,8 @@ \tcode{void** parray}, points to the first element of an arbitrary-length pointer array maintained for the private use of the program. -\exitnote \end{itemize} +\end{note} \rSec3[ios.types]{Types} @@ -888,11 +888,11 @@ An implementation is permitted to define \tcode{ios_base::failure} as a synonym for a class with equivalent functionality to class \tcode{ios_base::failure} shown in this subclause. -\enternote +\begin{note} When \tcode{ios_base::failure} is a synonym for another type it shall provide a nested type \tcode{failure}, to emulate the injected class name. -\exitnote +\end{note} The class \tcode{failure} defines the base class @@ -902,12 +902,12 @@ \pnum When throwing \tcode{ios_base::failure} exceptions, implementations should provide -values of \tcode{ec} that identify the specific reason for the failure. \enternote +values of \tcode{ec} that identify the specific reason for the failure. \begin{note} Errors arising from the operating system would typically be reported as \tcode{system_category()} errors with an error value of the error number reported by the operating system. Errors arising from within the stream library would typically be reported as \tcode{error_code(io_errc::stream, -iostream_category())}. \exitnote +iostream_category())}. \end{note} \indexlibrary{\idxcode{failure}!\idxcode{ios_base::failure}}% \begin{itemdecl} @@ -1714,7 +1714,7 @@ \end{libreqtab4c} \pnum -\enternote +\begin{note} Every implementation is required to supply overloaded operators on \tcode{fpos} objects to satisfy the requirements of~\ref{fpos.operations}. @@ -1722,7 +1722,7 @@ \tcode{fpos}, global operators, or provided in some other way. -\exitnote +\end{note} \pnum Stream operations that return a value of type @@ -2717,11 +2717,11 @@ \end{itemdescr} \pnum -\enternote The more obvious use of +\begin{note} The more obvious use of \tcode{ios_base::hex} to specify hexadecimal floating-point format would change the meaning of existing well defined programs. \CppIII gives no meaning to the combination of \tcode{fixed} and -\tcode{scientific}.\exitnote +\tcode{scientific}.\end{note} \indexlibrary{\idxcode{defaultfloat}}% \begin{itemdecl} @@ -4620,12 +4620,12 @@ stands for the private member of the \tcode{basic_ios} class. -\enternote +\begin{note} The first argument provides an object of the \tcode{istreambuf_iterator} class which is an iterator pointed to an input stream. It bypasses istreams and uses streambufs directly. -\exitnote +\end{note} Class \tcode{locale} relies on this @@ -5218,7 +5218,7 @@ \tcode{*this}. \pnum -\enterexample +\begin{example} \begin{codeblock} #include @@ -5243,7 +5243,7 @@ } } \end{codeblock} -\exitexample +\end{example} \end{itemdescr} \indexlibrary{\idxcode{getline}!\idxcode{basic_istream}}% @@ -5435,12 +5435,12 @@ \tcode{setstate(badbit)} (which may throw \tcode{ios_base::failure}~(\ref{iostate.flags})). -\enternote +\begin{note} This function extracts no characters, so the value returned by the next call to \tcode{gcount()} is 0. -\exitnote +\end{note} \pnum \returns @@ -5478,12 +5478,12 @@ \tcode{setstate(badbit)} (which may throw \tcode{ios_base::failure}~(\ref{iostate.flags})). -\enternote +\begin{note} This function extracts no characters, so the value returned by the next call to \tcode{gcount()} is 0. -\exitnote +\end{note} \pnum \returns @@ -7177,7 +7177,7 @@ \rSec2[quoted.manip]{Quoted manipulators} \pnum -\enternote Quoted manipulators provide string insertion and extraction of quoted strings (for example, XML and CSV formats). Quoted manipulators are useful in ensuring that the content of a string with embedded spaces remains unchanged if inserted and then extracted via stream I/O. \exitnote +\begin{note} Quoted manipulators provide string insertion and extraction of quoted strings (for example, XML and CSV formats). Quoted manipulators are useful in ensuring that the content of a string with embedded spaces remains unchanged if inserted and then extracted via stream I/O. \end{note} \indexlibrary{\idxcode{quoted}}% \begin{itemdecl} @@ -8471,11 +8471,11 @@ \end{codeblock} \pnum -\enternote The class template \tcode{basic_filebuf} treats a file as a source or +\begin{note} The class template \tcode{basic_filebuf} treats a file as a source or sink of bytes. In an environment that uses a large character set, the file typically holds multibyte character sequences and the \tcode{basic_filebuf} object converts those multibyte sequences into wide character sequences. -\exitnote +\end{note} \rSec2[filebuf]{Class template \tcode{basic_filebuf}} @@ -9982,9 +9982,9 @@ Some behavior is specified by reference to POSIX (\ref{fs.norm.ref}). How such behavior is actually implemented is unspecified. \pnum -\enternote This constitutes an ``as if'' rule allowing implementations +\begin{note} This constitutes an ``as if'' rule allowing implementations to call native -operating system or other APIs. \exitnote +operating system or other APIs. \end{note} \pnum Implementations are encouraged to provide such behavior as it is defined by @@ -9995,19 +9995,19 @@ reasonable behavior, the implementation shall report an error as specified in~\ref{fs.norm.ref}. \pnum -\enternote This allows users to rely on an exception being thrown or +\begin{note} This allows users to rely on an exception being thrown or an error code being set when an implementation cannot provide any reasonable -behavior.\exitnote +behavior.\end{note} \pnum Implementations are not required to provide behavior that is not supported by a particular file system. \pnum -\enterexample The FAT file system used by some memory cards, camera memory, and +\begin{example} The FAT file system used by some memory cards, camera memory, and floppy disks does not support hard links, symlinks, and many other features of more capable file systems, so implementations are not required to support those -features on the FAT file system. \exitexample +features on the FAT file system. \end{example} \rSec3[fs.conform.os]{Operating system dependent behavior conformance} \pnum @@ -10031,9 +10031,9 @@ \requires is not specified for the function. \pnum -\enternote As a design practice, preconditions are not specified when it +\begin{note} As a design practice, preconditions are not specified when it is unreasonable for a program to detect them prior to calling the function. -\exitnote +\end{note} \rSec2[fs.norm.ref]{Normative references} @@ -10084,8 +10084,8 @@ The name of a file. Filenames \grammarterm{dot} and \grammarterm{dot-dot} have special meaning. The following characteristics of filenames are operating system dependent: \begin{itemize} -\item The permitted characters. \enterexample Some operating systems prohibit - the ASCII control characters (0x00 -- 0x1F) in filenames. \exitexample. +\item The permitted characters. \begin{example} Some operating systems prohibit + the ASCII control characters (0x00 -- 0x1F) in filenames. \end{example}. \item The maximum permitted length. \item Filenames that are not permitted. \item Filenames that have special meaning. @@ -10099,8 +10099,8 @@ file systems support multiple hard links to a file. If the last hard link to a file is removed, the file itself is removed. -\enternote A hard link can be thought of as a shared-ownership smart -pointer to a file.\exitnote +\begin{note} A hard link can be thought of as a shared-ownership smart +pointer to a file.\end{note} \definitionx{link}{fs.def.link} A directory entry that associates a @@ -10129,7 +10129,7 @@ \defncontext{of a directory} the directory that both contains a directory entry for the given directory and is represented by the filename \grammarterm{dot-dot} in the given directory. -\enternote does not apply to \grammarterm{dot} and \grammarterm{dot-dot}. \exitnote +\begin{note} does not apply to \grammarterm{dot} and \grammarterm{dot-dot}. \end{note} \definitionx{parent directory}{fs.def.parent.other} \defncontext{of other types of files} a directory containing a directory @@ -10154,26 +10154,26 @@ Pathname resolution is the operating system dependent mechanism for resolving a pathname to a particular file in a file hierarchy. There may be multiple pathnames that resolve to the same file. -\enterexample POSIX specifies the mechanism in section 4.11, Pathname resolution. -\exitexample +\begin{example} POSIX specifies the mechanism in section 4.11, Pathname resolution. +\end{example} \definitionx{relative path}{fs.def.relative-path} A path that is not absolute, and so only unambiguously identifies the location of a file when resolved relative to an implied starting location. The elements of a path that determine if it is relative are operating system dependent. -\enternote +\begin{note} Pathnames ``.'' and ``..'' are relative paths. -\exitnote +\end{note} \definitionx{symbolic link}{fs.def.symlink} A type of file with the property that when the file is encountered during pathname resolution, a string stored by the file is used to modify the pathname resolution. -\enternote Symbolic links are often called symlinks. A symbolic link can be thought of as a raw pointer to a file. +\begin{note} Symbolic links are often called symlinks. A symbolic link can be thought of as a raw pointer to a file. If the file pointed to does not exist, the symbolic link is said to be a -``dangling'' symbolic link.\exitnote +``dangling'' symbolic link.\end{note} \rSec2[fs.req]{Requirements} @@ -10192,9 +10192,9 @@ have a value type that is one of the encoded character types. \pnum -\enternote Use of an encoded character type implies an associated +\begin{note} Use of an encoded character type implies an associated encoding. Since \tcode{signed char} and \tcode{unsigned char} have no -implied encoding, they are not included as permitted types. \exitnote +implied encoding, they are not included as permitted types. \end{note} \pnum Template parameters named \tcode{Allocator} shall meet the @@ -10424,7 +10424,7 @@ throws an exception to report file system errors, and another that sets an \tcode{error_code}. \pnum -\enternote This supports two common use cases: +\begin{note} This supports two common use cases: \begin{itemize} \item Uses where file system errors are truly exceptional @@ -10436,7 +10436,7 @@ Returning an error code is the most appropriate response. This allows application specific error handling, including simply ignoring the error. \end{itemize} -\exitnote +\end{note} \pnum Functions not having an argument of type \tcode{error_code\&} @@ -10623,14 +10623,14 @@ is the operating system dependent preferred-separator character~(\ref{path.generic}). \pnum -\enterexample +\begin{example} For POSIX based operating systems, \tcode{value_type} is \tcode{char} and \tcode{preferred_separator} is the slash character (\tcode{'/'}). For Windows based operating systems, \tcode{value_type} is \tcode{wchar_t} and \tcode{preferred_separator} is the backslash character (\tcode{L'\textbackslash'}). -\exitexample +\end{example} \rSec3[path.generic]{Generic pathname format} @@ -10644,7 +10644,7 @@ \begin{ncbnf} \nontermdef{root-name}\br \textnormal{An operating system dependent name that identifies the starting location for absolute paths. -\enternote Many operating systems define a name +\begin{note} Many operating systems define a name beginning with two \grammarterm{directory-separator} characters as a \grammarterm{root-name} that identifies network or other resource locations. @@ -10652,7 +10652,7 @@ define a single letter followed by a colon as a drive specifier -- a \grammarterm{root-name} identifying a specific device such as a disk drive. -\exitnote +\end{note} } \end{ncbnf} @@ -10678,7 +10678,7 @@ \begin{ncbnf} \nontermdef{name}\br \textnormal{A sequence of characters other than \grammarterm{directory-separator} characters. -\enternote +\begin{note} Operating systems often place restrictions on the characters that may be used in a \grammarterm{filename}. For wide portability, users may wish to limit \grammarterm{filename} @@ -10686,7 +10686,7 @@ \tcode{A B C D E F G H I J K L M N O P Q R S T U V W X Y Z} \\ \tcode{a b c d e f g h i j k l m n o p q r s t u v w x y z} \\ \tcode{0 1 2 3 4 5 6 7 8 9 . _ -} -\exitnote +\end{note} } \end{ncbnf} @@ -10734,7 +10734,7 @@ \rSec4[path.fmt.cvt]{\tcode{path} argument format conversions} \pnum -\enternote +\begin{note} The format conversions described in this section are not applied on POSIX or Windows based operating systems because on these systems: @@ -10743,7 +10743,7 @@ \item There is no need to distinguish between native format and generic format arguments. \item Paths for regular files and paths for directories share the same syntax. \end{itemize} -\exitnote +\end{note} \pnum Function arguments that take character sequences representing @@ -10754,12 +10754,12 @@ performed during the processing of the argument. \pnum -\enternote +\begin{note} Some operating systems may have no unambiguous way to distinguish between native format and generic format arguments. This is by design as it simplifies use for operating systems that do not require disambiguation. An implementation for an operating system where disambiguation is required is permitted to distinguish between the formats. -\exitnote +\end{note} \pnum If the native format requires paths for regular files to be formatted @@ -10780,26 +10780,26 @@ \begin{itemize} \item \tcode{char}: Encoding is the native narrow encoding (\ref{fs.def.native.encode}). Conversion, if any, is operating system dependent. -\enternote +\begin{note} For POSIX based operating systems \tcode{path::value_type} is \tcode{char} so no conversion from \tcode{char} value type arguments or to \tcode{char} value type returns is performed. For Windows based operating systems, the native narrow encoding is determined by calling a Windows API function. -\exitnote -\enternote +\end{note} +\begin{note} This results in behavior identical to other C and \Cpp standard library functions that perform file operations using narrow character strings to identify paths. Changing this behavior would be surprising and error prone. -\exitnote +\end{note} \item \tcode{wchar_t}: Encoding is the native wide encoding (\ref{fs.def.native.encode}). Conversion method is unspecified. -\enternote +\begin{note} For Windows based operating systems \tcode{path::value_type} is \tcode{wchar_t} so no conversion from \tcode{wchar_t} value type arguments or to \tcode{wchar_t} value type returns is performed. -\exitnote +\end{note} \item \tcode{char16_t}: Encoding is UTF-16. Conversion method is unspecified. \item \tcode{char32_t}: Encoding is UTF-32. Conversion method @@ -10835,11 +10835,11 @@ \end{itemize} \pnum -\enternote +\begin{note} See path conversions~(\ref{path.cvt}) for how these value types and their encodings convert to \tcode{path::value_type} and its encoding. -\exitnote +\end{note} \pnum Arguments of type \tcode{Source} @@ -10917,7 +10917,7 @@ \tcode{codecvt} facet of \tcode{loc}, and then a second conversion to the current narrow encoding. \end{itemize} -\enterexample +\begin{example} A string is to be read from a database that is encoded in ISO/IEC 8859-1, and used to create a directory: \begin{codeblock} @@ -10943,7 +10943,7 @@ \tcode{latin1_string} to a UTF-16 encoded wide character \tcode{pathname} string. All of the characters in the ISO/IEC 8859-1 character set will be converted to their Unicode representation. -\exitexample +\end{example} \end{itemdescr} \rSec4[path.assign]{\tcode{path} assignments} @@ -10972,7 +10972,7 @@ object, has no effect. Otherwise, modifies \tcode{pathname} to have the original value of \tcode{p.pathname}. \tcode{p} is left in a valid but unspecified state. -\enternote A valid implementation is \tcode{swap(p)}. \exitnote +\begin{note} A valid implementation is \tcode{swap(p)}. \end{note} \pnum \returns \tcode{*this} @@ -11015,7 +11015,7 @@ \item an added separator would be redundant, or \item would change a relative path to an absolute path - \enternote An empty path is relative.\exitnote, or + \begin{note} An empty path is relative.\end{note}, or \item \tcode{p.empty()}, or \item \tcode{*p.native().cbegin()} is a directory separator. \end{itemize} @@ -11123,7 +11123,7 @@ \returns \tcode{*this} \pnum -\enterexample +\begin{example} \begin{codeblock} path p("foo/bar"); std::cout << p << '\n'; @@ -11142,7 +11142,7 @@ "foo/bar" "foo\bar" \end{codeblock} -\exitexample +\end{example} \end{itemdescr} \indexlibrary{\idxcode{path}!\idxcode{remove_filename}} @@ -11159,12 +11159,12 @@ \returns \tcode{*this}. \pnum -\enterexample +\begin{example} \begin{codeblock} std::cout << path("/foo").remove_filename(); // outputs \tcode{"/"} std::cout << path("/").remove_filename(); // outputs \tcode{""} \end{codeblock} -\exitexample +\end{example} \end{itemdescr} \indexlibrary{\idxcode{path}!\idxcode{replace_filename}} @@ -11185,11 +11185,11 @@ \returns \tcode{*this}. \pnum -\enterexample +\begin{example} \begin{codeblock} std::cout << path("/").replace_filename("bar"); // outputs \tcode{"bar"} \end{codeblock} -\exitexample +\end{example} \end{itemdescr} \indexlibrary{\idxcode{path}!\idxcode{replace_extension}} @@ -11265,9 +11265,9 @@ \returns \tcode{pathname}. \pnum -\enternote Conversion to \tcode{string_type} is provided so that an +\begin{note} Conversion to \tcode{string_type} is provided so that an object of class \tcode{path} can be given as an argument to existing - standard library file stream constructors and open functions. \exitnote + standard library file stream constructors and open functions. \end{note} \end{itemdescr} \begin{itemdecl} @@ -11320,9 +11320,9 @@ the \textit{directory-separator} character. \pnum -\enterexample On an operating system that uses backslash as +\begin{example} On an operating system that uses backslash as its preferred-separator, \tcode{path("foo\textbackslash{}bar").generic_string()} -returns \tcode{"foo/bar"}. \exitexample +returns \tcode{"foo/bar"}. \end{example} \begin{itemdecl} template , @@ -11478,14 +11478,14 @@ \returns \tcode{empty() ? path() : *--end()} \pnum -\enterexample +\begin{example} \begin{codeblock} std::cout << path("/foo/bar.txt").filename(); // outputs "bar.txt" std::cout << path("/").filename(); // outputs "/" std::cout << path(".").filename(); // outputs "." std::cout << path("..").filename(); // outputs ".." \end{codeblock} -\exitexample +\end{example} \end{itemdescr} \indexlibrary{\idxcode{path}!\idxcode{stem}} @@ -11503,7 +11503,7 @@ returns \tcode{filename()}. \pnum -\enterexample +\begin{example} \begin{codeblock} std::cout << path("/foo/bar.txt").stem(); // outputs \tcode{"bar"} path p = "foo.bar.baz.tar"; @@ -11513,7 +11513,7 @@ // \tcode{.baz} // \tcode{.bar} \end{codeblock} -\exitexample +\end{example} \end{itemdescr} \indexlibrary{\idxcode{path}!\idxcode{extension}} @@ -11535,17 +11535,17 @@ as alternate data streams or partitioned dataset names. \pnum -\enterexample +\begin{example} \begin{codeblock} std::cout << path("/foo/bar.txt").extension(); // outputs ".txt" \end{codeblock} -\exitexample +\end{example} \pnum -\enternote The period is included in the return value so that it is +\begin{note} The period is included in the return value so that it is possible to distinguish between no extension and an empty extension. Also note that for a path \tcode{p}, \tcode{p.stem()+p.extension() == p.filename()}. - \exitnote + \end{note} \end{itemdescr} \rSec4[path.query]{\tcode{path} query} @@ -11661,9 +11661,9 @@ contains an absolute path (\ref{fs.def.absolute.path}), else \tcode{false}. \pnum -\enterexample \tcode{path("/").is_absolute()} is +\begin{example} \tcode{path("/").is_absolute()} is \tcode{true} for POSIX based operating systems, and \tcode{false} for Windows based -operating systems. \exitexample +operating systems. \end{example} \end{itemdescr} \indexlibrary{\idxcode{path}!\idxcode{is_relative}} @@ -11697,9 +11697,9 @@ \begin{itemize} \item The \textit{root-name} element, if present. \item The \textit{root-directory} element, if present, in the generic format. -\enternote +\begin{note} the generic format is required to ensure lexicographical -comparison works correctly. \exitnote +comparison works correctly. \end{note} \item Each successive \textit{filename} element, if present. \item \grammarterm{dot}, if one or more trailing non-root \textit{slash} characters are present. @@ -11801,7 +11801,7 @@ \indextext{path equality} \pnum -\enternote Path equality and path equivalence have different semantics. +\begin{note} Path equality and path equivalence have different semantics. \pnum Equality is determined by the \tcode{path} non-member \tcode{operator==}, which considers the two path's lexical @@ -11814,7 +11814,7 @@ \pnum Programmers wishing to determine if two paths are ``the same'' must decide if ``the same'' means ``the same representation'' or ``resolve to the same actual - file'', and choose the appropriate function accordingly. \exitnote + file'', and choose the appropriate function accordingly. \end{note} \end{itemdescr} \begin{itemdecl} @@ -11848,7 +11848,7 @@ \effects \tcode{os << quoted(p.string())}. \pnum -\enternote The \tcode{quoted} function is described in~\ref{quoted.manip}. \exitnote +\begin{note} The \tcode{quoted} function is described in~\ref{quoted.manip}. \end{note} \pnum \returns \tcode{os} @@ -11911,7 +11911,7 @@ unspecified. \pnum -\enterexample +\begin{example} A string is to be read from a database that is encoded in UTF-8, and used to create a directory using the native encoding for filenames: \begin{codeblock} @@ -11933,7 +11933,7 @@ \pnum For Windows based operating systems a conversion from UTF-8 to UTF-16 occurs. -\exitexample +\end{example} \end{itemdescr} @@ -12083,9 +12083,9 @@ The type of the file has not been determined or an error occurred while trying to determine the type. \\ \rowsep \tcode{not_found} & \tcode{-1} & -Pseudo-type indicating the file was not found. \enternote The file +Pseudo-type indicating the file was not found. \begin{note} The file not being found is not considered an error while determining the -type of a file. \exitnote \\ \rowsep +type of a file. \end{note} \\ \rowsep \tcode{regular} & \tcode{1} & Regular file \\ \rowsep \tcode{directory} & \tcode{2} & Directory file \\ \rowsep \tcode{symlink} & \tcode{3} & Symbolic link file \\ \rowsep @@ -12521,8 +12521,8 @@ An object of type \tcode{directory_iterator} provides an iterator for a sequence of \tcode{directory_entry} elements representing the files in a directory. -\enternote For iteration into sub-directories, see class \tcode{recursive_directory_iterator} -(\ref{class.rec.dir.itr}). \exitnote +\begin{note} For iteration into sub-directories, see class \tcode{recursive_directory_iterator} +(\ref{class.rec.dir.itr}). \end{note} \begin{codeblock} namespace std::filesystem { @@ -12592,7 +12592,7 @@ increments of a \tcode{directory_iterator} is unspecified. \pnum -\enternote +\begin{note} Programs performing directory iteration may wish to test if the path obtained by dereferencing a directory iterator actually exists. It could be a symbolic link to a non-existent file. Programs recursively @@ -12605,7 +12605,7 @@ unspecified whether or not subsequently incrementing the iterator will ever result in an iterator referencing the removed or added directory entry. See POSIX \tcode{readdir_r}. -\exitnote +\end{note} \rSec3[directory_iterator.members]{\tcode{directory_iterator} members} @@ -12644,7 +12644,7 @@ \throws As specified in Error reporting~(\ref{error.reporting}). \pnum -\enternote To iterate over the current directory, use \tcode{directory_iterator(".")} rather than \tcode{directory_iterator("")}. \exitnote +\begin{note} To iterate over the current directory, use \tcode{directory_iterator(".")} rather than \tcode{directory_iterator("")}. \end{note} \end{itemdescr} \begin{itemdecl} @@ -12780,8 +12780,8 @@ as a \tcode{directory_iterator} unless otherwise specified. \pnum -\enternote If the directory structure being iterated over contains cycles -then the end iterator may be unreachable. \exitnote +\begin{note} If the directory structure being iterated over contains cycles +then the end iterator may be unreachable. \end{note} \rSec3[rec.dir.itr.members]{\tcode{recursive_directory_iterator} members} @@ -12825,13 +12825,13 @@ \throws As specified in Error reporting~(\ref{error.reporting}). \pnum -\enternote To iterate over the current directory, use \tcode{recursive_directory_iterator(".")} - rather than \tcode{recursive_directory_iterator("")}. \exitnote +\begin{note} To iterate over the current directory, use \tcode{recursive_directory_iterator(".")} + rather than \tcode{recursive_directory_iterator("")}. \end{note} \pnum -\enternote By default, \tcode{recursive_directory_iterator} does not +\begin{note} By default, \tcode{recursive_directory_iterator} does not follow directory symlinks. To follow directory symlinks, specify \tcode{options} as -\tcode{directory_options::follow_directory_symlink} \exitnote +\tcode{directory_options::follow_directory_symlink} \end{note} \end{itemdescr} \begin{itemdecl} @@ -12929,9 +12929,9 @@ \requires \tcode{*this != recursive_directory_iterator()}. \pnum -\returns The current depth of the directory tree being traversed. \enternote +\returns The current depth of the directory tree being traversed. \begin{note} The initial directory is depth 0, its immediate subdirectories are depth 1, - and so forth. \exitnote + and so forth. \end{note} \pnum \throws Nothing. @@ -13024,8 +13024,8 @@ \postcondition \tcode{recursion_pending() == false}. \pnum -\enternote \tcode{disable_recursion_pending}\tcode{()} is used to prevent - unwanted recursion into a directory. \exitnote +\begin{note} \tcode{disable_recursion_pending}\tcode{()} is used to prevent + unwanted recursion into a directory. \end{note} \end{itemdescr} \rSec3[rec.dir.itr.nonmembers]{\tcode{recursive_directory_iterator} non-member functions} @@ -13059,10 +13059,10 @@ in external storage. \pnum -\enternote Because hardware failures, network failures, file system races, and many +\begin{note} Because hardware failures, network failures, file system races, and many other kinds of errors occur frequently in file system operations, users should be aware that any filesystem operation function, no matter how apparently innocuous, may encounter -an error. See Error reporting~(\ref{error.reporting}). \exitnote +an error. See Error reporting~(\ref{error.reporting}). \end{note} \rSec3[fs.op.absolute]{Absolute} @@ -13097,7 +13097,7 @@ \end{lib2dtab2base} \pnum -\enternote For the returned path, \tcode{rp,} \tcode{rp.is_absolute()} is true. \exitnote +\begin{note} For the returned path, \tcode{rp,} \tcode{rp.is_absolute()} is true. \end{note} \pnum \throws As specified in Error reporting~(\ref{error.reporting}). @@ -13233,7 +13233,7 @@ library functions called by the implementation shall have an \tcode{error_code} argument if applicable. \pnum -\enterexample Given this directory structure: +\begin{example} Given this directory structure: \begin{codeblock} /dir1 file1 @@ -13269,7 +13269,7 @@ dir2 file3 \end{codeblock} -\exitexample +\end{example} \end{itemdescr} @@ -13428,12 +13428,12 @@ attributes copied from directory \tcode{existing_p}. The set of attributes copied is operating system dependent. Creation failure because \tcode{p} resolves to an existing directory shall not be treated as an error. -\enternote For POSIX based operating systems the +\begin{note} For POSIX based operating systems the attributes are those copied by native API \tcode{stat(existing_p.c_str(), \&attributes_stat)} followed by \tcode{mkdir(p.c_str(), attributes_stat.st_mode)}. For Windows based operating systems the attributes are those copied by native API \tcode{CreateDirectoryExW(existing_p.c_str(), p.c_str(), 0)}. -\exitnote +\end{note} \pnum \postcondition \tcode{is_directory(p)}. @@ -13468,15 +13468,15 @@ \throws As specified in Error reporting~(\ref{error.reporting}). \pnum -\enternote Some operating systems require symlink creation to - identify that the link is to a directory. Portable code should use \tcode{create_directory_symlink()} to create directory symlinks rather than \tcode{create_symlink()} \exitnote +\begin{note} Some operating systems require symlink creation to + identify that the link is to a directory. Portable code should use \tcode{create_directory_symlink()} to create directory symlinks rather than \tcode{create_symlink()} \end{note} \pnum -\enternote Some operating systems do not support symbolic links at all or support +\begin{note} Some operating systems do not support symbolic links at all or support them only for regular files. Some file systems (such as the FAT file system) do not support - symbolic links regardless of the operating system. \exitnote + symbolic links regardless of the operating system. \end{note} \end{itemdescr} \rSec3[fs.op.create_hard_lk]{Create hard link} @@ -13504,10 +13504,10 @@ \throws As specified in Error reporting~(\ref{error.reporting}). \pnum -\enternote Some operating systems do not support hard links at all or support +\begin{note} Some operating systems do not support hard links at all or support them only for regular files. Some file systems (such as the FAT file system) do not support hard links regardless of the operating system. - Some file systems limit the number of links per file. \exitnote + Some file systems limit the number of links per file. \end{note} \end{itemdescr} \rSec3[fs.op.create_symlink]{Create symlink} @@ -13531,10 +13531,10 @@ \throws As specified in Error reporting~(\ref{error.reporting}). \pnum -\enternote Some operating systems do not support symbolic links at all or support +\begin{note} Some operating systems do not support symbolic links at all or support them only for regular files. Some file systems (such as the FAT file system) do not - support symbolic links regardless of the operating system. \exitnote + support symbolic links regardless of the operating system. \end{note} \end{itemdescr} \rSec3[fs.op.current_path]{Current path} @@ -13561,13 +13561,13 @@ for relative paths. \pnum -\enternote The \tcode{current_path()} name was chosen to emphasize that the return is a +\begin{note} The \tcode{current_path()} name was chosen to emphasize that the return is a path, not just a single directory name. \pnum The current path as returned by many operating systems is a dangerous global variable. It may be changed unexpectedly by a third-party or system - library functions, or by another thread. \exitnote + library functions, or by another thread. \end{note} \end{itemdescr} \indexlibrary{\idxcode{current_path}} @@ -13587,9 +13587,9 @@ \throws As specified in Error reporting~(\ref{error.reporting}). \pnum -\enternote The current path for many operating systems is a dangerous +\begin{note} The current path for many operating systems is a dangerous global state. It may be changed unexpectedly by a third-party or system - library functions, or by another thread. \exitnote + library functions, or by another thread. \end{note} \end{itemdescr} \rSec3[fs.op.exists]{Exists} @@ -13895,9 +13895,9 @@ \begin{itemdescr} \pnum -\effects Sets \tcode{ec} as if by \tcode{status(p, ec)}. \enternote +\effects Sets \tcode{ec} as if by \tcode{status(p, ec)}. \begin{note} \tcode{file_type::none}, \tcode{file_type::not_found} and - \tcode{file_type::unknown} cases set \tcode{ec} to error values. To distinguish between cases, call the \tcode{status} function directly. \exitnote + \tcode{file_type::unknown} cases set \tcode{ec} to error values. To distinguish between cases, call the \tcode{status} function directly. \end{note} \pnum \returns \tcode{is_regular_file(status(p, ec))}. @@ -13999,8 +13999,8 @@ \throws As specified in Error reporting~(\ref{error.reporting}). \pnum -\enternote A postcondition of \tcode{last_write_time(p) == new_time} is not specified since it might not hold for file systems - with coarse time granularity. \exitnote +\begin{note} A postcondition of \tcode{last_write_time(p) == new_time} is not specified since it might not hold for file systems + with coarse time granularity. \end{note} \end{itemdescr} \rSec3[fs.op.permissions]{Permissions} @@ -14034,8 +14034,8 @@ \end{floattable} \pnum -\enternote Conceptually permissions are viewed as bits, but the actual - implementation may use some other mechanism. \exitnote +\begin{note} Conceptually permissions are viewed as bits, but the actual + implementation may use some other mechanism. \end{note} \pnum \throws As specified in Error reporting~(\ref{error.reporting}). @@ -14057,8 +14057,8 @@ returns \tcode{path()} if an error occurs. \pnum -\throws As specified in Error reporting~(\ref{error.reporting}). \enternote It is an error if \tcode{p} does not - resolve to a symbolic link. \exitnote +\throws As specified in Error reporting~(\ref{error.reporting}). \begin{note} It is an error if \tcode{p} does not + resolve to a symbolic link. \end{note} \end{itemdescr} @@ -14076,8 +14076,8 @@ removed as if by POSIX \tcode{remove()}. \pnum -\enternote A symbolic link is itself removed, rather than the file it - resolves to being removed. \exitnote +\begin{note} A symbolic link is itself removed, rather than the file it + resolves to being removed. \end{note} \pnum \postcondition \tcode{!exists(symlink_status(p))}. @@ -14106,8 +14106,8 @@ then deletes file \tcode{p} itself, as if by POSIX \tcode{remove()}. \pnum -\enternote A symbolic link is itself removed, rather than the file it - resolves to being removed. \exitnote +\begin{note} A symbolic link is itself removed, rather than the file it + resolves to being removed. \end{note} \pnum \postcondition \tcode{!exists(p)}. @@ -14136,12 +14136,12 @@ POSIX \tcode{rename()}. \pnum -\enternote If \tcode{old_p} and \tcode{new_p} resolve to the +\begin{note} If \tcode{old_p} and \tcode{new_p} resolve to the same existing file, no action is taken. Otherwise, if \tcode{new_p} resolves to an existing non-directory file, it is removed, while if \tcode{new_p} resolves to an existing directory, it is removed if empty on POSIX compliant operating systems but is an error on some other operating systems. A symbolic link is itself renamed, rather than - the file it resolves to being renamed. \exitnote + the file it resolves to being renamed. \end{note} \pnum \throws As specified in Error reporting~(\ref{error.reporting}). @@ -14194,8 +14194,8 @@ \pnum \remarks The value of member \tcode{space_info::available} - is operating system dependent. \enternote \tcode{available} may be - less than \tcode{free}. \exitnote + is operating system dependent. \begin{note} \tcode{available} may be + less than \tcode{free}. \end{note} \end{itemdescr} @@ -14222,9 +14222,9 @@ \pnum \throws \tcode{filesystem_error}. -\enternote \tcode{result} values of \tcode{file_status(file_type::not_found)} +\begin{note} \tcode{result} values of \tcode{file_status(file_type::not_found)} and \tcode{file_status(file_type::unknown)} are not considered failures and do not - cause an exception to be thrown.\exitnote + cause an exception to be thrown.\end{note} \end{itemdescr} \indexlibrary{\idxcode{status}} @@ -14242,9 +14242,9 @@ Otherwise, \tcode{ec.clear()}. \pnum -\enternote This allows users to inspect the specifics of underlying +\begin{note} This allows users to inspect the specifics of underlying API errors even when the value returned by \tcode{status()} is not - \tcode{file_status(file_type::none)}. \exitnote + \tcode{file_status(file_type::none)}. \end{note} \pnum \returns @@ -14260,23 +14260,23 @@ \end{itemize} \pnum -\enternote These semantics distinguish between \tcode{p} being known not to exist, \tcode{p} existing but not being able to determine its attributes, +\begin{note} These semantics distinguish between \tcode{p} being known not to exist, \tcode{p} existing but not being able to determine its attributes, and there being an error that prevents even knowing if \tcode{p} exists. These - distinctions are important to some use cases. \exitnote + distinctions are important to some use cases. \end{note} \pnum Otherwise, \begin{itemize} \item If the attributes indicate a regular file, as if by POSIX \tcode{S_ISREG}, - return \tcode{file_status(file_type::regular)}. \enternote + return \tcode{file_status(file_type::regular)}. \begin{note} \tcode{file_type::regular} implies appropriate \tcode{} operations would succeed, assuming no hardware, permission, access, or file system race errors. Lack of \tcode{file_type::regular} does not necessarily imply - \tcode{} operations would fail on a directory. \exitnote + \tcode{} operations would fail on a directory. \end{note} \item Otherwise, if the attributes indicate a directory, as if by POSIX \tcode{S_ISDIR}, return \tcode{file_status(file_type::directory)}. - \enternote \tcode{file_type::directory} implies - \tcode{directory_iterator(p)} would succeed. \exitnote + \begin{note} \tcode{file_type::directory} implies + \tcode{directory_iterator(p)} would succeed. \end{note} \item Otherwise, if the attributes indicate a block special file, as if by POSIX \tcode{S_ISBLK}, return \tcode{file_status(file_type::block)}. \item Otherwise, if the attributes indicate a character special file, as if @@ -14361,7 +14361,7 @@ \throws As specified in Error reporting~(\ref{error.reporting}). \pnum -\enterexample For POSIX based operating systems, \tcode{system_complete(p)} +\begin{example} For POSIX based operating systems, \tcode{system_complete(p)} has the same semantics as \tcode{absolute(p, current_path())}. \pnum @@ -14374,7 +14374,7 @@ be the current directory for that drive the last time it was set, and thus may be residue left over from a prior program run by the command processor. Although these semantics are useful, they may be surprising. -\exitexample +\end{example} \end{itemdescr} @@ -14397,7 +14397,7 @@ \throws As specified in Error reporting~(\ref{error.reporting}). \pnum -\enterexample For POSIX based operating systems, an implementation might +\begin{example} For POSIX based operating systems, an implementation might return the path supplied by the first environment variable found in the list TMPDIR, TMP, TEMP, TEMPDIR, or if none of these are found, \tcode{"/tmp"}. @@ -14405,14 +14405,14 @@ \pnum For Windows based operating systems, an implementation might return the path reported by the Windows \tcode{GetTempPath} API function. -\exitexample +\end{example} \end{itemdescr} \rSec1[c.files]{C library files} \pnum Table~\ref{tab:iostreams.hdr.cstdio} describes header \tcode{}. -\enternote \Cpp does not define the function \tcode{gets}. \exitnote +\begin{note} \Cpp does not define the function \tcode{gets}. \end{note} \begin{libsyntab6}{cstdio}{tab:iostreams.hdr.cstdio} \cspan{\macros} \\ @@ -14502,10 +14502,10 @@ ISO C 7.9, Amendment 1 4.6.2. \pnum -Table~\ref{tab:iostreams.hdr.cinttypes} describes header \tcode{}. \enternote The +Table~\ref{tab:iostreams.hdr.cinttypes} describes header \tcode{}. \begin{note} The macros defined by \tcode{} are provided unconditionally. In particular, the symbol \tcode{__STDC_FORMAT_MACROS}, mentioned in footnote 182 of the C standard, plays no role in -\Cpp. \exitnote +\Cpp. \end{note} \begin{libsyntab4}{cinttypes}{tab:iostreams.hdr.cinttypes} \cspan{\macros} \\ diff --git a/source/iterators.tex b/source/iterators.tex index 4fac4a4043..0b641f5f4a 100644 --- a/source/iterators.tex +++ b/source/iterators.tex @@ -115,14 +115,14 @@ dereferenceable iterator values \tcode{a} and \tcode{(a + n)}, \tcode{*(a + n)} is equivalent to \tcode{*(addressof(*a) + n)}, are called \defn{contiguous iterators}. -\enternote +\begin{note} For example, the type ``pointer to \tcode{int}'' is a contiguous iterator, but \tcode{reverse_iterator} is not. For a valid iterator range $[$\tcode{a}$, $\tcode{b}$)$ with dereferenceable \tcode{a}, the corresponding range denoted by pointers is $[$\tcode{addressof(*a)}$, $\tcode{addressof(*a) + (b - a)}$)$; \tcode{b} might not be dereferenceable. -\exitnote +\end{note} \pnum Just as a regular pointer to an array guarantees that there is a pointer value pointing past the last element @@ -140,23 +140,23 @@ The library never assumes that past-the-end values are dereferenceable. Iterators can also have singular values that are not associated with any sequence. -\enterexample +\begin{example} After the declaration of an uninitialized pointer \tcode{x} (as with \tcode{int* x;}), \tcode{x} must always be assumed to have a singular value of a pointer. -\exitexample +\end{example} Results of most expressions are undefined for singular values; the only exceptions are destroying an iterator that holds a singular value, the assignment of a non-singular value to an iterator that holds a singular value, and, for iterators that satisfy the \tcode{DefaultConstructible} requirements, using a value-initialized iterator -as the source of a copy or move operation. \enternote This guarantee is not +as the source of a copy or move operation. \begin{note} This guarantee is not offered for default initialization, although the distinction only matters for types with trivial default constructors such as pointers or aggregates holding pointers. -\exitnote +\end{note} In these cases the singular value is overwritten the same way as any other value. Dereferenceable @@ -244,8 +244,8 @@ \tcode{T}, \tcode{o} denotes a value of some type that is writable to the output iterator. -\enternote For an iterator type \tcode{X} there must be an instantiation -of \tcode{iterator_traits}~(\ref{iterator.traits}). \exitnote +\begin{note} For an iterator type \tcode{X} there must be an instantiation +of \tcode{iterator_traits}~(\ref{iterator.traits}). \end{note} \rSec2[iterator.iterators]{Iterator} @@ -319,7 +319,7 @@ \tcode{==} for the iterator values it uses. These requirements can be inferred from the uses that algorithm makes of \tcode{==} and \tcode{!=}. -\enterexample +\begin{example} the call \tcode{find(a,b,x)} is defined only if the value of \tcode{a} has the property \textit{p} @@ -335,7 +335,7 @@ \tcode{++i} has property \tcode{p}). -\exitexample +\end{example} \begin{libreqtab4b} {Input iterator requirements (in addition to Iterator)} @@ -386,7 +386,7 @@ \end{libreqtab4b} \pnum -\enternote +\begin{note} For input iterators, \tcode{a == b} does not imply @@ -400,7 +400,7 @@ These algorithms can be used with istreams as the source of the input data through the \tcode{istream_iterator} class template. -\exitnote +\end{note} \rSec2[output.iterators]{Output iterators} @@ -452,7 +452,7 @@ \end{libreqtab4b} \pnum -\enternote +\begin{note} The only valid use of an \tcode{operator*} is on the left side of the assignment statement. @@ -466,7 +466,7 @@ for placing data through the \tcode{ostream_iterator} class as well as with insert iterators and insert pointers. -\exitnote +\end{note} \rSec2[forward.iterators]{Forward iterators} @@ -494,8 +494,8 @@ The domain of == for forward iterators is that of iterators over the same underlying sequence. However, value-initialized iterators may be compared and shall compare equal to other value-initialized iterators of the same type. -\enternote value initialized iterators behave as if they refer past the end of -the same empty sequence \exitnote +\begin{note} value initialized iterators behave as if they refer past the end of +the same empty sequence \end{note} \pnum Two dereferenceable iterators \tcode{a} and \tcode{b} of type \tcode{X} offer the @@ -508,7 +508,7 @@ \end{itemize} \pnum -\enternote +\begin{note} The requirement that \tcode{a == b} implies @@ -518,7 +518,7 @@ a mutable iterator (which applies to output iterators) allows the use of multi-pass one-directional algorithms with forward iterators. -\exitnote +\end{note} \begin{libreqtab4b} {Forward iterator requirements (in addition to input iterator)} @@ -593,9 +593,9 @@ \end{libreqtab4b} \pnum -\enternote +\begin{note} Bidirectional iterators allow algorithms to move iterators backward as well as forward. -\exitnote +\end{note} \rSec2[random.access.iterators]{Random access iterators} @@ -944,7 +944,7 @@ \end{codeblock} \pnum -\enterexample +\begin{example} To implement a generic \tcode{reverse} function, a \Cpp program can do the following: @@ -964,7 +964,7 @@ } } \end{codeblock} -\exitexample +\end{example} \rSec2[iterator.basic]{Basic iterator} @@ -1034,7 +1034,7 @@ \indexlibrary{\idxcode{forward_iterator_tag}}% \indexlibrary{\idxcode{bidirectional_iterator_tag}}% \indexlibrary{\idxcode{random_access_iterator_tag}}% -\enterexample +\begin{example} For a program-defined iterator \tcode{BinaryTreeIterator}, it could be included @@ -1056,10 +1056,10 @@ \tcode{BinaryTreeIterator} from \tcode{iterator}. -\exitexample +\end{example} \pnum -\enterexample +\begin{example} If \tcode{evolve()} is well defined for bidirectional iterators, but can be implemented more @@ -1085,10 +1085,10 @@ // more efficient, but less generic algorithm } \end{codeblock} -\exitexample +\end{example} \pnum -\enterexample +\begin{example} If a \Cpp program wants to define a bidirectional iterator for some data structure containing \tcode{double} and such that it @@ -1105,7 +1105,7 @@ Then there is no need to specialize the \tcode{iterator_traits} template. -\exitexample +\end{example} \rSec2[iterator.operations]{Iterator operations} @@ -2147,7 +2147,7 @@ copying with moving. \pnum -\enterexample +\begin{example} \begin{codeblock} list s; @@ -2157,7 +2157,7 @@ make_move_iterator(s.end())); // moves strings into \tcode{v2} \end{codeblock} -\exitexample +\end{example} \rSec3[move.iterator]{Class template \tcode{move_iterator}} @@ -2606,7 +2606,7 @@ class templates are provided. -\enterexample +\begin{example} \begin{codeblock} partial_sum(istream_iterator(cin), istream_iterator(), @@ -2617,7 +2617,7 @@ \tcode{cin}, and prints the partial sums onto \tcode{cout}. -\exitexample +\end{example} \rSec2[istream.iterator]{Class template \tcode{istream_iterator}} @@ -3022,7 +3022,7 @@ from the streambuf for which it was constructed. \tcode{operator*} provides access to the current input character, if any. -\enternote \tcode{operator->} may return a proxy. \exitnote +\begin{note} \tcode{operator->} may return a proxy. \end{note} Each time \tcode{operator++} is evaluated, the iterator advances to the next input character. diff --git a/source/lex.tex b/source/lex.tex index cf3a92f415..71760defb6 100644 --- a/source/lex.tex +++ b/source/lex.tex @@ -34,18 +34,18 @@ directive \tcode{\#include}, less any source lines skipped by any of the conditional inclusion~(\ref{cpp.cond}) preprocessing directives, is called a \defn{translation unit}. -\enternote A \Cpp program need not all be translated at the same time. -\exitnote +\begin{note} A \Cpp program need not all be translated at the same time. +\end{note} \pnum -\enternote Previously translated translation units and instantiation +\begin{note} Previously translated translation units and instantiation units can be preserved individually or in libraries. The separate translation units of a program communicate~(\ref{basic.link}) by (for example) calls to functions whose identifiers have external linkage, manipulation of objects whose identifiers have external linkage, or manipulation of data files. Translation units can be separately translated and then later linked to produce an executable -program~(\ref{basic.link}). \exitnote% +program~(\ref{basic.link}). \end{note}% \indextext{compilation!separate|)} \rSec1[lex.phases]{Phases of translation}% @@ -108,10 +108,10 @@ than new-line is retained or replaced by one space character is unspecified. The process of dividing a source file's characters into preprocessing tokens is context-dependent. -\enterexample +\begin{example} see the handling of \tcode{<} within a \tcode{\#include} preprocessing directive. -\exitexample +\end{example} \item Preprocessing directives are executed, macro invocations are expanded, and \tcode{_Pragma} unary operator expressions are executed. @@ -136,31 +136,31 @@ \item White-space characters separating tokens are no longer significant. Each preprocessing token is converted into a token.~(\ref{lex.token}). The resulting tokens are syntactically and -semantically analyzed and translated as a translation unit. \enternote +semantically analyzed and translated as a translation unit. \begin{note} The process of analyzing and translating the tokens may occasionally result in one token being replaced by a sequence of other -tokens~(\ref{temp.names}).\exitnote \enternote Source files, translation +tokens~(\ref{temp.names}).\end{note} \begin{note} Source files, translation units and translated translation units need not necessarily be stored as files, nor need there be any one-to-one correspondence between these entities and any external representation. The description is conceptual -only, and does not specify any particular implementation. \exitnote +only, and does not specify any particular implementation. \end{note} \item Translated translation units and instantiation units are combined -as follows: \enternote Some or all of these may be supplied from a -library. \exitnote Each translated translation unit is examined to -produce a list of required instantiations. \enternote This may include +as follows: \begin{note} Some or all of these may be supplied from a +library. \end{note} Each translated translation unit is examined to +produce a list of required instantiations. \begin{note} This may include instantiations which have been explicitly -requested~(\ref{temp.explicit}). \exitnote The definitions of the +requested~(\ref{temp.explicit}). \end{note} The definitions of the required templates are located. It is \impldef{whether source of translation units must be available to locate template definitions} whether the source of the translation units containing these definitions is required -to be available. \enternote An implementation could encode sufficient +to be available. \begin{note} An implementation could encode sufficient information into the translated translation unit so as to ensure the -source is not required here. \exitnote All the required instantiations +source is not required here. \end{note} All the required instantiations are performed to produce -\defn{instantiation units}. \enternote These are similar +\defn{instantiation units}. \begin{note} These are similar to translated translation units, but contain no references to -uninstantiated templates and no template definitions. \exitnote The +uninstantiated templates and no template definitions. \end{note} The program is ill-formed if any instantiation fails. \item All external entity references are resolved. Library @@ -321,28 +321,28 @@ within a \tcode{\#include} directive~(\ref{cpp.include}). \end{itemize} -\enterexample +\begin{example} \begin{codeblock} #define R "x" const char* s = R"y"; // ill-formed raw string, not \tcode{"x" "y"} \end{codeblock} -\exitexample +\end{example} \pnum -\enterexample The program fragment \tcode{0xe+foo} is parsed as a +\begin{example} The program fragment \tcode{0xe+foo} is parsed as a preprocessing number token (one that is not a valid floating or integer literal token), even though a parse as three preprocessing tokens \tcode{0xe}, \tcode{+}, and \tcode{foo} might produce a valid expression (for example, if \tcode{foo} were a macro defined as \tcode{1}). Similarly, the program fragment \tcode{1E1} is parsed as a preprocessing number (one that is a valid floating literal token), whether or not \tcode{E} is a -macro name. \exitexample +macro name. \end{example} \pnum -\enterexample The program fragment \tcode{x+++++y} is parsed as \tcode{x +\begin{example} The program fragment \tcode{x+++++y} is parsed as \tcode{x ++ ++ + y}, which, if \tcode{x} and \tcode{y} have integral types, violates a constraint on increment operators, even though the parse -\tcode{x ++ + ++ y} might yield a correct expression. \exitexample% +\tcode{x ++ + ++ y} might yield a correct expression. \end{example}% \indextext{token!preprocessing|)} \rSec1[lex.digraph]{Alternative tokens} @@ -408,10 +408,10 @@ \indextext{white~space}% Blanks, horizontal and vertical tabs, newlines, formfeeds, and comments (collectively, ``white space''), as described below, are ignored except -as they serve to separate tokens. \enternote Some white space is +as they serve to separate tokens. \begin{note} Some white space is required to separate otherwise adjacent identifiers, keywords, numeric literals, and alternative tokens containing alphabetic characters. -\exitnote% +\end{note}% \indextext{token|)} \rSec1[lex.comment]{Comments} @@ -427,11 +427,11 @@ next new-line character. If there is a form-feed or a vertical-tab character in such a comment, only white-space characters shall appear between it and the new-line that terminates the comment; no diagnostic -is required. \enternote The comment characters \tcode{//}, \tcode{/*}, +is required. \begin{note} The comment characters \tcode{//}, \tcode{/*}, and \tcode{*/} have no special meaning within a \tcode{//} comment and are treated just like other characters. Similarly, the comment characters \tcode{//} and \tcode{/*} have no special meaning within a -\tcode{/*} comment. \exitnote% +\tcode{/*} comment. \end{note}% \indextext{comment|)} \rSec1[lex.header]{Header names} @@ -466,8 +466,8 @@ \end{bnf} \pnum -\enternote Header name preprocessing tokens only appear within a -\tcode{\#include} preprocessing directive (see~\ref{lex.pptoken}). \exitnote +\begin{note} Header name preprocessing tokens only appear within a +\tcode{\#include} preprocessing directive (see~\ref{lex.pptoken}). \end{note} The sequences in both forms of \grammarterm{header-name}{s} are mapped in an \impldef{mapping header name to header or external source file} manner to headers or to external source file names as specified in~\ref{cpp.include}. @@ -610,8 +610,8 @@ The identifiers shown in Table~\ref{tab:keywords} are reserved for use as keywords (that is, they are unconditionally treated as keywords in phase 7) except in an \grammarterm{attribute-token}~(\ref{dcl.attr.grammar}) -\enternote The \tcode{export} and \tcode{register} keywords are unused but -are reserved for future use.\exitnote: +\begin{note} The \tcode{export} and \tcode{register} keywords are unused but +are reserved for future use.\end{note}: \begin{floattable}{Keywords}{tab:keywords} {lllll} @@ -892,11 +892,11 @@ digits, which include the decimal digits and the letters \tcode{a} through \tcode{f} and \tcode{A} through \tcode{F} with decimal values ten through fifteen. -\enterexample The number twelve can be written \tcode{12}, \tcode{014}, +\begin{example} The number twelve can be written \tcode{12}, \tcode{014}, \tcode{0XC}, or \tcode{0b1100}. The literals \tcode{1048576}, \tcode{1'048'576}, \tcode{0X100000}, \tcode{0x10'0000}, and \tcode{0'004'000'000} all have the same value. -\exitexample +\end{example} \pnum \indextext{literal!\idxcode{long}}% @@ -1124,9 +1124,9 @@ of the \grammarterm{c-char} in the execution wide-character set, unless the \grammarterm{c-char} has no representation in the execution wide-character set, in which case the value is \impldef{value of wide-character literal with single c-char that is -not in execution wide-character set}. \enternote The type \tcode{wchar_t} is able to +not in execution wide-character set}. \begin{note} The type \tcode{wchar_t} is able to represent all members of the execution wide-character set (see~\ref{basic.fundamental}). -\exitnote. The value +\end{note}. The value of a wide-character literal containing multiple \grammarterm{c-char}{s} is \impldef{value of wide-character literal containing multiple characters}. @@ -1189,24 +1189,24 @@ corresponding type} if it falls outside of the implementation-defined range defined for \tcode{char} (for literals with no prefix) or \tcode{wchar_t} (for literals prefixed by \tcode{L}). -\enternote +\begin{note} If the value of a character literal prefixed by \tcode{u}, \tcode{u8}, or \tcode{U} is outside the range defined for its type, the program is ill-formed. -\exitnote +\end{note} \pnum A universal-character-name is translated to the encoding, in the appropriate execution character set, of the character named. If there is no such encoding, the universal-character-name is translated to an \impldef{encoding of universal character name not in execution character set} encoding. -\enternote In translation phase 1, a universal-character-name is introduced whenever an +\begin{note} In translation phase 1, a universal-character-name is introduced whenever an actual extended character is encountered in the source text. Therefore, all extended characters are described in terms of universal-character-names. However, the actual compiler implementation may use its own native character set, -so long as the same results are obtained. \exitnote +so long as the same results are obtained. \end{note} \rSec2[lex.fcon]{Floating literals} @@ -1293,8 +1293,8 @@ Optional separating single quotes in a \grammarterm{digit-sequence} or \grammarterm{hexadecimal-digit-sequence} are ignored when determining its value. -\enterexample The literals \tcode{1.602'176'565e-19} and \tcode{1.602176565e-19} -have the same value. \exitexample +\begin{example} The literals \tcode{1.602'176'565e-19} and \tcode{1.602176565e-19} +have the same value. \end{example} Either the integer part or the fraction part (not both) can be omitted. Either the radix point or the letter \tcode{e} or \tcode{E} and the exponent (not both) can be omitted from a decimal floating literal. @@ -1306,9 +1306,9 @@ indicates the power of 10 by which the significand is to be scaled. In a hexadecimal floating literal, the exponent indicates the power of 2 by which the significand is to be scaled. -\enterexample +\begin{example} The literals \tcode{49.625} and \tcode{0xC.68p+2} have the same value. -\exitexample +\end{example} If the scaled value is in the range of representable values for its type, the result is the scaled value if representable, else the larger or smaller representable value @@ -1423,12 +1423,12 @@ shall consist of at most 16 characters. \pnum -\enternote The characters \tcode{'('} and \tcode{')'} are permitted in a +\begin{note} The characters \tcode{'('} and \tcode{')'} are permitted in a \grammarterm{raw-string}. Thus, \tcode{R"delimiter((a|b))delimiter"} is equivalent to -\tcode{"(a|b)"}. \exitnote +\tcode{"(a|b)"}. \end{note} \pnum -\enternote A source-file new-line in a raw string literal results in a new-line in the +\begin{note} A source-file new-line in a raw string literal results in a new-line in the resulting execution string literal. Assuming no whitespace at the beginning of lines in the following example, the assert will succeed: @@ -1438,10 +1438,10 @@ c)"; assert(std::strcmp(p, "a\\\nb\nc") == 0); \end{codeblock} -\exitnote +\end{note} \pnum -\enterexample The raw string +\begin{example} The raw string \begin{codeblock} R"a( @@ -1464,7 +1464,7 @@ )#" \end{codeblock} -is equivalent to \tcode{"\textbackslash n)\textbackslash?\textbackslash?=\textbackslash"\textbackslash n"}. \exitexample +is equivalent to \tcode{"\textbackslash n)\textbackslash?\textbackslash?=\textbackslash"\textbackslash n"}. \end{example} \pnum \indextext{string!type~of}% @@ -1528,13 +1528,13 @@ the same \grammarterm{encoding-prefix} as the other operand. If a UTF-8 string literal token is adjacent to a wide string literal token, the program is ill-formed. Any other concatenations are conditionally-supported with \impldef{concatenation of some types of string literals} -behavior. \enternote This +behavior. \begin{note} This concatenation is an interpretation, not a conversion. Because the interpretation happens in translation phase 6 (after each character from a literal has been translated into a value from the appropriate character set), a \grammarterm{string-literal}'s initial rawness has no effect on the interpretation or well-formedness of the concatenation. -\exitnote +\end{note} Table~\ref{tab:lex.string.concat} has some examples of valid concatenations. \begin{floattable}{String literal concatenations}{tab:lex.string.concat} @@ -1559,7 +1559,7 @@ Characters in concatenated strings are kept distinct. -\enterexample +\begin{example} \begin{codeblock} "\xA" "B" \end{codeblock} @@ -1567,7 +1567,7 @@ contains the two characters \tcode{'\textbackslash xA'} and \tcode{'B'} after concatenation (and not the single hexadecimal character \tcode{'\textbackslash xAB'}). -\exitexample +\end{example} \pnum \indextext{\idxcode{0}|seealso{zero,~null}}% @@ -1596,9 +1596,9 @@ literal is the total number of escape sequences, universal-character-names, and other characters, plus one for each character requiring a surrogate pair, plus one for the terminating -\tcode{u'\textbackslash 0'}. \enternote The size of a \tcode{char16_t} +\tcode{u'\textbackslash 0'}. \begin{note} The size of a \tcode{char16_t} string literal is the number of code units, not the number of -characters. \exitnote Within \tcode{char32_t} and \tcode{char16_t} +characters. \end{note} Within \tcode{char32_t} and \tcode{char16_t} literals, any universal-character-names shall be within the range \tcode{0x0} to \tcode{0x10FFFF}. The size of a narrow string literal is the total number of escape sequences and other characters, plus at least @@ -1614,9 +1614,9 @@ nonoverlapping objects) and whether successive evaluations of a \grammarterm{string-literal} yield the same or a different object is unspecified. -\enternote +\begin{note} \indextext{literal!string!undefined change~to}% -The effect of attempting to modify a string literal is undefined. \exitnote +The effect of attempting to modify a string literal is undefined. \end{note} \rSec2[lex.bool]{Boolean literals} @@ -1643,12 +1643,12 @@ \pnum The pointer literal is the keyword \tcode{nullptr}. It is a prvalue of type \tcode{std::nullptr_t}. -\enternote +\begin{note} \tcode{std::nullptr_t} is a distinct type that is neither a pointer type nor a pointer to member type; rather, a prvalue of this type is a null pointer constant and can be converted to a null pointer value or null member pointer value. See~\ref{conv.ptr} and~\ref{conv.mem}. -\exitnote +\end{note} \rSec2[lex.ext]{User-defined literals} @@ -1694,9 +1694,9 @@ \pnum If a token matches both \grammarterm{user-defined-literal} and another literal kind, it -is treated as the latter. \enterexample \tcode{123_km} +is treated as the latter. \begin{example} \tcode{123_km} is a \grammarterm{user-defined-literal}, but \tcode{12LL} is an -\grammarterm{integer-literal}. \exitexample +\grammarterm{integer-literal}. \end{example} The syntactic non-terminal preceding the \grammarterm{ud-suffix} in a \grammarterm{user-defined-literal} is taken to be the longest sequence of characters that could match that non-terminal. @@ -1736,9 +1736,9 @@ operator "" @\term{X}@<'@$c_1$@', '@$c_2$@', ... '@$c_k$@'>() \end{codeblock} -where \term{n} is the source character sequence $c_1c_2...c_k$. \enternote The sequence +where \term{n} is the source character sequence $c_1c_2...c_k$. \begin{note} The sequence $c_1c_2...c_k$ can only contain characters from the basic source character set. -\exitnote +\end{note} \pnum If \term{L} is a \grammarterm{user-defined-floating-literal}, let \term{f} be the @@ -1765,9 +1765,9 @@ operator "" @\term{X}@<'@$c_1$@', '@$c_2$@', ... '@$c_k$@'>() \end{codeblock} -where \term{f} is the source character sequence $c_1c_2...c_k$. \enternote The sequence +where \term{f} is the source character sequence $c_1c_2...c_k$. \begin{note} The sequence $c_1c_2...c_k$ can only contain characters from the basic source character set. -\exitnote +\end{note} \pnum If \term{L} is a \grammarterm{user-defined-string-literal}, let \term{str} be the @@ -1794,7 +1794,7 @@ \end{codeblock} \pnum -\enterexample +\begin{example} \begin{codeblock} long double operator "" _w(long double); @@ -1808,7 +1808,7 @@ } \end{codeblock} -\exitexample +\end{example} \pnum In translation phase 6~(\ref{lex.phases}), adjacent string literals are concatenated and @@ -1821,13 +1821,13 @@ and that suffix is applied to the result of the concatenation. \pnum -\enterexample +\begin{example} \begin{codeblock} int main() { L"A" "B" "C"_x; // OK: same as \tcode{L"ABC"_x} "P"_x "Q" "R"_y;// error: two different \grammarterm{ud-suffix}{es} } \end{codeblock} -\exitexample% +\end{example}% \indextext{literal|)}% \indextext{conventions!lexical|)} diff --git a/source/lib-intro.tex b/source/lib-intro.tex index 1883ae76b0..a9980140a2 100755 --- a/source/lib-intro.tex +++ b/source/lib-intro.tex @@ -124,7 +124,7 @@ \indexdefn{stream!arbitrary-positional}% a stream (described in Clause~\ref{input.output}) that can seek to any integral position within the length of the stream\\ -\enternote Every arbitrary-positional stream is also a repositional stream. \exitnote +\begin{note} Every arbitrary-positional stream is also a repositional stream. \end{note} \definition{block}{defns.block} \indexdefn{block}% @@ -141,7 +141,7 @@ any object which, when treated sequentially, can represent text\\ -\enternote +\begin{note} The term does not mean only \tcode{char}, \tcode{char16_t}, @@ -151,18 +151,18 @@ objects, but any value that can be represented by a type that provides the definitions specified in these Clauses. -\exitnote +\end{note} \definition{character container type}{defns.character.container} \indexdefn{type!character container}% a class or a type used to represent a \term{character}\\ -\enternote +\begin{note} It is used for one of the template parameters of the string, iostream, and regular expression class templates. A character container type is a POD~(\ref{basic.types}) type. -\exitnote +\end{note} \definition{comparison function}{defns.comparison} \indexdefn{function!comparison}% @@ -173,7 +173,7 @@ \indexdefn{component}% a group of library entities directly related as members, parameters, or return types\\ -\enternote +\begin{note} For example, the class template \tcode{basic_string} and the non-member @@ -181,7 +181,7 @@ that operate on strings are referred to as the \term{string component}. -\exitnote +\end{note} \definition{constant subexpression}{defns.const.subexpr} \indexdefn{constant subexpression}% @@ -216,16 +216,16 @@ a \term{non-reserved function} whose definition may be provided by a \Cpp program\\ -\enternote +\begin{note} A \Cpp program may designate a handler function at various points in its execution by supplying a pointer to the function when calling any of the library functions that install handler functions (Clause~\ref{language.support}). -\exitnote +\end{note} \definition{iostream class templates}{defns.iostream.templates} templates, defined in Clause~\ref{input.output}, that take two template arguments\\ -\enternote +\begin{note} The arguments are named \tcode{charT} and @@ -239,7 +239,7 @@ of the character type represented by \tcode{charT} necessary to implement the iostream class templates. -\exitnote +\end{note} \definition{modifier function}{defns.modifier} \indexdefn{function!modifier}% @@ -267,38 +267,38 @@ \definition{object state}{defns.obj.state} \indexdefn{state!object}% the current value of all non-static class members of an object~(\ref{class.mem})\\ -\enternote +\begin{note} The state of an object can be obtained by using one or more \term{observer functions}. -\exitnote +\end{note} \definition{observer function}{defns.observer} \indexdefn{function!observer}% a class member function~(\ref{class.mfct}) that accesses the state of an object of the class but does not alter that state\\ -\enternote +\begin{note} Observer functions are specified as \tcode{const} member functions~(\ref{class.this}). -\exitnote +\end{note} \definition{referenceable type}{defns.referenceable} \indexdefn{type!referenceable} An object type, a function type that does not have cv-qualifiers or a \grammarterm{ref-qualifier}, or a reference type. -\enternote The term describes a type to which a reference can be created, -including reference types. \exitnote +\begin{note} The term describes a type to which a reference can be created, +including reference types. \end{note} \definition{replacement function}{defns.replacement} \indexdefn{function!replacement}% a \term{non-reserved function} whose definition is provided by a \Cpp program\\ -\enternote +\begin{note} Only one definition for such a function is in effect for the duration of the program's execution, as the result of creating the program~(\ref{lex.phases}) and resolving the definitions of all translation units~(\ref{basic.link}). -\exitnote +\end{note} \definition{repositional stream}{defns.repositional.stream} \indexdefn{stream!repositional}% @@ -314,37 +314,37 @@ semantics applicable to both the behavior provided by the implementation and the behavior of any such function definition in the program\\ -\enternote +\begin{note} If such a function defined in a \Cpp program fails to meet the required behavior when it executes, the behavior is undefined.% \indextext{undefined} -\exitnote +\end{note} \definition{reserved function}{defns.reserved.function} \indexdefn{function!reserved}% a function, specified as part of the \Cpp standard library, that must be defined by the implementation\\ -\enternote +\begin{note} If a \Cpp program provides a definition for any reserved function, the results are undefined.% \indextext{undefined} -\exitnote +\end{note} \definition{stable algorithm}{defns.stable} \indexdefn{algorithm!stable}% \indexdefn{stable algorithm}% an algorithm that preserves, as appropriate to the particular algorithm, the order of elements\\ -\enternote Requirements for stable algorithms are given in~\ref{algorithm.stable}. \exitnote +\begin{note} Requirements for stable algorithms are given in~\ref{algorithm.stable}. \end{note} \definition{traits class}{defns.traits} \indexdefn{traits}% a class that encapsulates a set of types and functions necessary for class templates and function templates to manipulate objects of types for which they are instantiated\\ -\enternote +\begin{note} Traits classes defined in Clauses~\ref{strings}, \ref{localization} and~\ref{input.output} are \term{character traits}, which provide the character handling support needed by the string and iostream classes. -\exitnote +\end{note} \definition{unblock}{defns.unblock} \indexdefn{unblock}% @@ -354,10 +354,10 @@ \indexdefn{valid but unspecified state}% an object state that is not specified except that the object's invariants are met and operations on the object behave as specified for its type\\ -\enterexample If an object \tcode{x} of type \tcode{std::vector} is in a +\begin{example} If an object \tcode{x} of type \tcode{std::vector} is in a valid but unspecified state, \tcode{x.empty()} can be called unconditionally, and \tcode{x.front()} can be called only if \tcode{x.empty()} returns -\tcode{false}. \exitexample +\tcode{false}. \end{example} \rSec1[defns.additional]{Additional definitions} @@ -867,8 +867,8 @@ For the sake of exposition, the library clauses sometimes annotate constructors with \EXPLICIT{}. Such a constructor is conditionally declared as either explicit or non-explicit~(\ref{class.conv.ctor}). -\enternote This is typically implemented by declaring two such constructors, -of which at most one participates in overload resolution. \exitnote +\begin{note} This is typically implemented by declaring two such constructors, +of which at most one participates in overload resolution. \end{note} \rSec3[objects.within.classes]{Private members} @@ -1117,9 +1117,9 @@ \pnum Names which are defined as macros in C shall be defined as macros in the \Cpp standard library, even if C grants license for implementation as functions. -\enternote The names defined as macros in C include the following: +\begin{note} The names defined as macros in C include the following: \tcode{assert}, \tcode{offsetof}, \tcode{setjmp}, \tcode{va_arg}, -\tcode{va_end}, and \tcode{va_start}. \exitnote +\tcode{va_end}, and \tcode{va_start}. \end{note} \pnum Names that are defined as functions in C shall be defined as functions in the @@ -1360,9 +1360,9 @@ \tcode{T(rv)} is equivalent to the value of \tcode{rv} before the construction \\ \rowsep \multicolumn{2}{|p{5.3in}|}{ \tcode{rv}'s state is unspecified - \enternote \tcode{rv} must still meet the requirements of the library + \begin{note} \tcode{rv} must still meet the requirements of the library component that is using it. The operations listed in those requirements must - work as specified whether \tcode{rv} has been moved from or not. \exitnote}\\ + work as specified whether \tcode{rv} has been moved from or not. \end{note}}\\ \end{concepttable} \indextext{requirements!\idxcode{CopyConstructible}}% @@ -1384,9 +1384,9 @@ to the value of \tcode{rv} before the assignment\\ \rowsep \multicolumn{4}{|p{5.3in}|}{ \tcode{rv}'s state is unspecified. - \enternote\ \tcode{rv} must still meet the requirements of the library + \begin{note}\ \tcode{rv} must still meet the requirements of the library component that is using it. The operations listed in those requirements must - work as specified whether \tcode{rv} has been moved from or not. \exitnote}\\ + work as specified whether \tcode{rv} has been moved from or not. \end{note}}\\ \end{concepttable} \indextext{requirements!\idxcode{CopyAssignable}}% @@ -1439,15 +1439,15 @@ \item the lookup set produced by argument-dependent lookup~(\ref{basic.lookup.argdep}). \end{itemize} -\enternote If \tcode{T} and \tcode{U} are both fundamental types or arrays of +\begin{note} If \tcode{T} and \tcode{U} are both fundamental types or arrays of fundamental types and the declarations from the header \tcode{} are in scope, the overall lookup set described above is equivalent to that of the qualified name lookup applied to the expression \tcode{std::swap(t, u)} or -\tcode{std::swap(u, t)} as appropriate. \exitnote +\tcode{std::swap(u, t)} as appropriate. \end{note} -\enternote It is unspecified whether a library component that has a swappable +\begin{note} It is unspecified whether a library component that has a swappable requirement includes the header \tcode{} to ensure an appropriate -evaluation context. \exitnote +evaluation context. \end{note} \pnum An rvalue or lvalue \tcode{t} is \defn{swappable} if and only if \tcode{t} is @@ -1460,7 +1460,7 @@ \tcode{x} of type \tcode{X}, \tcode{*x} is swappable. -\enterexample User code can ensure that the evaluation of \tcode{swap} calls +\begin{example} User code can ensure that the evaluation of \tcode{swap} calls is performed in an appropriate context under the various conditions as follows: \begin{codeblock} #include @@ -1502,7 +1502,7 @@ assert(a1.m == -5 && a2.m == 5); } \end{codeblock} -\exitexample +\end{example} \rSec3[nullablepointer.requirements]{\tcode{NullablePointer} requirements} @@ -1526,8 +1526,8 @@ \pnum A value-initialized object of type \tcode{P} produces the null value of the type. The null value shall be equivalent only to itself. A default-initialized object -of type \tcode{P} may have an indeterminate value. \enternote Operations involving -indeterminate values may cause undefined behavior. \exitnote +of type \tcode{P} may have an indeterminate value. \begin{note} Operations involving +indeterminate values may cause undefined behavior. \end{note} \pnum An object \tcode{p} of type \tcode{P} can be contextually converted to @@ -1609,12 +1609,12 @@ \tcode{h(k)} & \tcode{size_t} & The value returned shall depend only on the argument \tcode{k} for the duration of - the program. \enternote Thus all evaluations of the expression \tcode{h(k)} with the + the program. \begin{note} Thus all evaluations of the expression \tcode{h(k)} with the same value for \tcode{k} yield the same result for a given execution of the program. - \exitnote \enternote For two different + \end{note} \begin{note} For two different values \tcode{t1} and \tcode{t2}, the probability that \tcode{h(t1)} and \tcode{h(t2)} compare equal should be very small, approaching \tcode{1.0 / numeric_limits::max()}. - \exitnote \\ \rowsep + \end{note} \\ \rowsep \tcode{h(u)} & \tcode{size_t} & Shall not modify \tcode{u}. \\ @@ -1765,9 +1765,9 @@ \tcode{a.allocate(n)} & \tcode{X::pointer} & Memory is allocated for \tcode{n} objects of type \tcode{T} but objects are not constructed. \tcode{allocate} may raise an appropriate exception.\footnotemark -\enternote +\begin{note} If \tcode{n == 0}, the return value is unspecified. -\exitnote & \\ \rowsep +\end{note} & \\ \rowsep \tcode{a.allocate(n, y)} & \tcode{X::pointer} & @@ -1881,12 +1881,12 @@ \pnum Note A: The member class template \tcode{rebind} in the table above is -effectively a typedef template. \enternote In general, if +effectively a typedef template. \begin{note} In general, if the name \tcode{Allocator} is bound to \tcode{SomeAllocator}, then \tcode{Allocator::rebind::other} is the same type as \tcode{SomeAllocator}, where \tcode{SomeAllocator::value_type} is \tcode{T} and -\tcode{SomeAllocator::\brk{}value_type} is \tcode{U}. \exitnote If +\tcode{SomeAllocator::\brk{}value_type} is \tcode{U}. \end{note} If \tcode{Allocator} is a class template instantiation of the form \tcode{SomeAllocator}, where \tcode{Args} is zero or more type arguments, and \tcode{Allocator} does not supply a \tcode{rebind} member @@ -1962,7 +1962,7 @@ called. If a type cannot be used with a particular allocator, the allocator class or the call to \tcode{construct} or \tcode{destroy} may fail to instantiate. -\enterexample the following is an allocator class template supporting the minimal +\begin{example} the following is an allocator class template supporting the minimal interface that satisfies the requirements of Table~\ref{tab:utilities.allocator.requirements}: @@ -1983,15 +1983,15 @@ template bool operator!=(const SimpleAllocator&, const SimpleAllocator&); \end{codeblock} -\exitexample +\end{example} \pnum If the alignment associated with a specific over-aligned type is not supported by an allocator, instantiation of the allocator for that type may fail. The allocator also may silently ignore the requested alignment. -\enternote Additionally, the member function \tcode{allocate} +\begin{note} Additionally, the member function \tcode{allocate} for that type may fail by throwing an object of type -\tcode{std::bad_alloc}.\exitnote +\tcode{std::bad_alloc}.\end{note} \rSec4[allocator.requirements.completeness]{Allocator completeness requirements} @@ -2450,15 +2450,15 @@ \item If a function argument binds to an rvalue reference parameter, the implementation may assume that this parameter is a unique reference to this argument. -\enternote +\begin{note} If the parameter is a generic parameter of the form \tcode{T\&\&} and an lvalue of type \tcode{A} is bound, the argument binds to an lvalue reference~(\ref{temp.deduct.call}) -and thus is not covered by the previous sentence. \exitnote \enternote If a program casts +and thus is not covered by the previous sentence. \end{note} \begin{note} If a program casts an lvalue to an xvalue while passing that lvalue to a library function (e.g. by calling the function with the argument \tcode{std::move(x)}), the program is effectively asking that function to treat that lvalue as a temporary. The implementation is free to optimize away aliasing checks which might be needed if the argument was -an lvalue. \exitnote +an lvalue. \end{note} \end{itemize} \rSec3[res.on.objects]{Library object access} @@ -2466,9 +2466,9 @@ \pnum The behavior of a program is undefined if calls to standard library functions from different threads may introduce a data race. The conditions under which this may occur are specified -in~\ref{res.on.data.races}. \enternote Modifying an object of a standard library type that is +in~\ref{res.on.data.races}. \begin{note} Modifying an object of a standard library type that is shared between threads risks undefined behavior unless objects of that type are explicitly -specified as being sharable without data races or the user supplies a locking mechanism. \exitnote +specified as being sharable without data races or the user supplies a locking mechanism. \end{note} \pnum If an object of a standard library type is accessed, and @@ -2476,9 +2476,9 @@ does not happen before the access, or the access does not happen before the end of the object's lifetime, the behavior is undefined unless otherwise specified. -\enternote +\begin{note} This applies even to objects such as mutexes intended for thread synchronization. -\exitnote +\end{note} \rSec3[res.on.required]{Requires paragraph} @@ -2567,7 +2567,7 @@ Unless otherwise specified, global and non-member functions in the standard library shall not use functions from another namespace which are found through \term{argument-dependent name lookup}~(\ref{basic.lookup.argdep}). -\enternote +\begin{note} The phrase ``unless otherwise specified'' is intended to allow argument-dependent lookup in cases like that of @@ -2580,7 +2580,7 @@ *@\textit{out_stream}@ << @\textit{delim}@; return *this; \end{codeblock} -\exitnote +\end{note} \rSec3[member.functions]{Member functions} @@ -2594,12 +2594,12 @@ provided that any call to the member function that would select an overload from the set of declarations described in this standard behaves as if that overload were selected. -\enternote +\begin{note} For instance, an implementation may add parameters with default values, or replace a member function with default arguments with two or more member functions with equivalent behavior, or add additional signatures for a member function name. -\exitnote +\end{note} \rSec3[constexpr.functions]{\tcode{constexpr} functions and constructors} @@ -2660,9 +2660,9 @@ arguments, including \tcode{this}. \pnum -\enternote This means, for example, that implementations can't use a static object for +\begin{note} This means, for example, that implementations can't use a static object for internal purposes without synchronization because it could cause a data race even in -programs that do not explicitly share objects between threads. \exitnote +programs that do not explicitly share objects between threads. \end{note} \pnum A \Cpp standard library function shall not access objects indirectly accessible via its @@ -2672,8 +2672,8 @@ \pnum Operations on iterators obtained by calling a standard library container or string member function may access the underlying container, but shall not modify it. -\enternote In particular, container operations that invalidate iterators conflict -with operations on iterators associated with that container. \exitnote +\begin{note} In particular, container operations that invalidate iterators conflict +with operations on iterators associated with that container. \end{note} \pnum Implementations may share their own internal objects between threads if the objects are @@ -2685,9 +2685,9 @@ visible~(\ref{intro.multithread}) to users. \pnum -\enternote This allows implementations to parallelize operations if there are no visible +\begin{note} This allows implementations to parallelize operations if there are no visible \indextext{side effects}% -side effects. \exitnote +side effects. \end{note} \rSec3[protection.within.classes]{Protection within classes} @@ -2810,11 +2810,11 @@ \indextext{pointer!to traceable object}% Objects constructed by the standard library that may hold a user-supplied pointer value or an integer of type \tcode{std::intptr_t} shall store such values in a traceable -pointer location~(\ref{basic.stc.dynamic.safety}). \enternote Other libraries are +pointer location~(\ref{basic.stc.dynamic.safety}). \begin{note} Other libraries are strongly encouraged to do the same, since not doing so may result in accidental use of pointers that are not safely derived. Libraries that store pointers outside the user's address space should make it appear that they are stored and retrieved from a traceable -pointer location. \exitnote +pointer location. \end{note} \rSec3[value.error.codes]{Value of error codes} @@ -2826,13 +2826,13 @@ \impldef{error_category@\tcode{error_category} for errors originating outside the operating system} \tcode{error_category} object for errors originating elsewhere. The implementation shall define the possible values of \tcode{value()} for each of these -error categories. \enterexample For operating systems that are based on POSIX, +error categories. \begin{example} For operating systems that are based on POSIX, implementations are encouraged to define the \tcode{std::system_category()} values as identical to the POSIX \tcode{errno} values, with additional values as defined by the operating system's documentation. Implementations for operating systems that are not based on POSIX are encouraged to define values identical to the operating system's values. For errors that do not originate from the operating system, the implementation -may provide enums for the associated values. \exitexample +may provide enums for the associated values. \end{example} \rSec3[lib.types.movedfrom]{Moved-from state of library types} diff --git a/source/locales.tex b/source/locales.tex index 38e0905310..684653c972 100644 --- a/source/locales.tex +++ b/source/locales.tex @@ -176,7 +176,7 @@ \tcode{has_facet<>}. \pnum -\enterexample +\begin{example} An iostream \tcode{operator\shl} might be implemented as:\footnote{Note that in the call to @@ -199,7 +199,7 @@ return s; } \end{codeblock} -\exitexample +\end{example} \pnum In the call to @@ -220,7 +220,7 @@ may standard facets~(\ref{facets.examples}). \pnum -\enternote +\begin{note} All locale semantics are accessed via \tcode{use_facet<>} and @@ -244,8 +244,8 @@ object \tcode{loc} a \Cpp program can call \tcode{isspace(c,loc)}. (This eases upgrading existing extractors~(\ref{istream.formatted}).) -\exitnote \end{itemize} +\end{note} \pnum Once a facet reference is obtained from a locale object by calling @@ -551,7 +551,7 @@ and to encapsulate initialization. \pnum -\enternote +\begin{note} Because facets are used by iostreams, potentially while static constructors are running, their initialization cannot depend on programmed static initialization. @@ -561,7 +561,7 @@ \tcode{id} member the first time an instance of the facet is installed into a locale. This depends only on static storage being zero before constructors run~(\ref{basic.start.static}). -\exitnote +\end{note} \rSec3[locale.cons]{\tcode{locale} constructors and destructor} @@ -581,12 +581,12 @@ if it has been called; else, the resulting facets have virtual function semantics identical to those of \tcode{locale::classic()}. -\enternote +\begin{note} This constructor is commonly used as the default value for arguments of functions that take a \tcode{const locale\&} argument. -\exitnote +\end{note} \end{itemdescr} \indexlibrary{\idxcode{locale}!constructor}% @@ -855,7 +855,7 @@ \end{codeblock} \pnum -\enterexample +\begin{example} A vector of strings \tcode{v} can be collated according to collation rules in locale @@ -865,7 +865,7 @@ \begin{codeblock} std::sort(v.begin(), v.end(), loc); \end{codeblock} -\exitexample +\end{example} \end{itemdescr} \rSec3[locale.statics]{\tcode{locale} static members} @@ -897,8 +897,8 @@ \tcode{locale\colcol{}global()} shall affect the value returned by \tcode{locale()}. -\enternote See~\ref{c.locales} for data race considerations when -\tcode{setlocale} is invoked. \exitnote +\begin{note} See~\ref{c.locales} for data race considerations when +\tcode{setlocale} is invoked. \end{note} \pnum \returns @@ -1053,7 +1053,7 @@ Class template \tcode{wstring_convert} performs conversions between a wide string and a byte string. It lets you specify a code conversion facet (like class template \tcode{codecvt}) to perform the conversions, without -affecting any streams or locales. \enterexample If you want to use the code +affecting any streams or locales. \begin{example} If you want to use the code conversion facet \tcode{codecvt_utf8} to output to \tcode{cout} a UTF-8 multibyte sequence corresponding to a wide string, but you don't want to alter the locale for \tcode{cout}, you can write something like: @@ -1063,7 +1063,7 @@ std::string mbstring = myconv.to_bytes(L"Hello\n"); std::cout << mbstring; \end{codeblock} -\exitexample +\end{example} \pnum \synopsis{Class template \tcode{wstring_convert} synopsis} @@ -2579,16 +2579,16 @@ \tcode{basic_filebuf} must be able to translate characters one internal character at a time. } -\enternote As a result of operations on \tcode{state}, it can return \tcode{ok} or \tcode{partial} and set \tcode{from_next == from} and \tcode{to_next != to}. \exitnote +\begin{note} As a result of operations on \tcode{state}, it can return \tcode{ok} or \tcode{partial} and set \tcode{from_next == from} and \tcode{to_next != to}. \end{note} \pnum \remarks Its operations on \tcode{state} are unspecified. -\enternote +\begin{note} This argument can be used, for example, to maintain shift state, to specify conversion options (such as count only), or to identify a cache of seek offsets. -\exitnote +\end{note} \pnum \returns @@ -3211,7 +3211,7 @@ \tcode{(str.failbit|str.eofbit)} if the reason for the failure was that \tcode{(in == end)}. -\enterexample +\begin{example} For targets \tcode{true}: \tcode{"a"} @@ -3241,7 +3241,7 @@ \tcode{err == str.goodbit}. For empty targets \tcode{("")}, any input sequence yields \tcode{err == str.failbit}. -\exitexample +\end{example} \pnum \returns @@ -4005,11 +4005,11 @@ on any other string for which \tcode{do_compare()} returns 0 (equal) when passed the two strings. -\enternote +\begin{note} The probability that the result equals that for another string which does not compare equal should be very small, approaching \tcode{(1.0/numeric_limits::max())}. -\exitnote +\end{note} \end{itemdescr} \rSec3[locale.collate.byname]{Class template \tcode{collate_byname}} @@ -4278,11 +4278,11 @@ \end{itemize} \pnum -\enternote The function uses the \tcode{ctype} +\begin{note} The function uses the \tcode{ctype} facet installed in \tcode{f}'s locale to determine valid whitespace characters. It is unspecified by what means the function performs case-insensitive comparison or whether -multi-character sequences are considered while doing so. \exitnote +multi-character sequences are considered while doing so. \end{note} \pnum \returns \tcode{s} @@ -4585,11 +4585,11 @@ \tcode{do_put(s, str, fill, t, format, modifier)}. \pnum -\enternote +\begin{note} The \tcode{fill} argument may be used in the implementation-defined formats or by derivations. A space character is a reasonable default for this argument. -\exitnote +\end{note} \pnum \returns @@ -4627,11 +4627,11 @@ \pnum \returns An iterator pointing immediately after the last character produced. -\enternote +\begin{note} The \tcode{fill} argument may be used in the implementation-defined formats or by derivations. A space character is a reasonable default for this argument. -\exitnote +\end{note} \end{itemdescr} \rSec3[locale.time.put.byname]{Class template \tcode{time_put_byname}} @@ -4790,7 +4790,7 @@ inclusive) stored in \tcode{digits}. -\enterexample +\begin{example} The sequence \tcode{\$1,056.23} in a common United States locale would yield, for @@ -4799,7 +4799,7 @@ or, for \tcode{digits}, \tcode{"105623"}. -\exitexample +\end{example} If \tcode{mp.grouping()} indicates that no thousands separators are permitted, @@ -4838,7 +4838,7 @@ \tcode{sign} in the format pattern, it is consumed and any remaining characters in the string are required after all the other format components. -\enterexample +\begin{example} If \tcode{showbase} is off, then for a @@ -4848,7 +4848,7 @@ but if \tcode{neg} is \tcode{"-"}, the \tcode{"L"} in \tcode{"-100 L"} is not consumed. -\exitexample +\end{example} If \tcode{pos} or @@ -5054,11 +5054,11 @@ \tcode{(af == str.left)} is true, they are placed after the other characters; otherwise, they are placed before the other characters. -\enternote +\begin{note} It is possible, with some combinations of format patterns and flag values, to produce output that cannot be parsed using \tcode{num_get<>::get}. -\exitnote +\end{note} \pnum \returns @@ -5631,12 +5631,12 @@ \tcode{static locale::id id}. \pnum -\enternote +\begin{note} The locale member function templates verify its type and storage class. -\exitnote +\end{note} \pnum -\enterexample +\begin{example} Traditional global localization is still easy: \begin{codeblock} @@ -5656,10 +5656,10 @@ return MyObject(argc, argv).doit(); } \end{codeblock} -\exitexample +\end{example} \pnum -\enterexample +\begin{example} Greater flexibility is possible: \begin{codeblock} @@ -5679,14 +5679,14 @@ \tcode{3.456,78}, output is \tcode{3456.78}. -\exitexample +\end{example} \pnum This can be important even for simple programs, which may need to write a data file in a fixed format, regardless of a user's preference. \pnum -\enterexample +\begin{example} Here is an example of the use of locales in a library interface. \begin{codeblock} @@ -5747,7 +5747,7 @@ return s; } \end{codeblock} -\exitexample +\end{example} \pnum A locale object may be extended with a new facet simply by constructing @@ -5758,7 +5758,7 @@ which identifies your class interface as a new facet. \pnum -\enterexample +\begin{example} Classifying Japanese characters: \begin{codeblock} @@ -5796,10 +5796,10 @@ \pnum The new facet is used exactly like the built-in facets. -\exitexample +\end{example} \pnum -\enterexample +\begin{example} Replacing an existing facet is even easier. The code does not define a member \tcode{id} @@ -5834,7 +5834,7 @@ return 0; } \end{codeblock} -\exitexample +\end{example} \rSec1[locale.stdcvt]{Standard code conversion facets} diff --git a/source/macros.tex b/source/macros.tex index dbb1ad5e17..77bf48c955 100644 --- a/source/macros.tex +++ b/source/macros.tex @@ -144,12 +144,18 @@ \newcommand{\leftshift}[1]{\ensuremath{\, \mathsf{lshift}_#1 \,}} %% Notes and examples -\newcommand{\EnterBlock}[1]{[\,\textit{#1:}\xspace} -\newcommand{\ExitBlock}[1]{\textit{\,---\,end #1}\,]\xspace} -\newcommand{\enternote}{\EnterBlock{Note}} -\newcommand{\exitnote}{\ExitBlock{note}} -\newcommand{\enterexample}{\EnterBlock{Example}} -\newcommand{\exitexample}{\ExitBlock{example}} +\newenvironment{note}[1][Note]{% + [\,\textit{#1:}\space +}{% + \textit{\,---\,end note}\,]% +} + +\newenvironment{example}[1][Example]{% + [\,\textit{#1:}\space +}{% + \textit{\,---\,end example}\,]% +} + %% Library function descriptions \newcommand{\Fundescx}[1]{\textit{#1}\xspace} diff --git a/source/numerics.tex b/source/numerics.tex index 21e8d697b3..07535a20cc 100644 --- a/source/numerics.tex +++ b/source/numerics.tex @@ -92,13 +92,13 @@ initialization of its raw storage using the copy constructor, is semantically equivalent to assignment to the original object. -\enternote +\begin{note} This rule states that there shall not be any subtle differences in the semantics of initialization versus assignment. This gives an implementation considerable flexibility in how arrays are initialized. -\enterexample +\begin{example} An implementation is allowed to initialize a \tcode{valarray} by allocating storage using the @@ -108,7 +108,7 @@ assigning each element its value. Or the implementation can allocate raw storage and use the copy constructor to initialize each element. -\exitexample +\end{example} If the distinction between initialization and assignment is important for a class, or if it fails to satisfy any of @@ -116,7 +116,7 @@ \tcode{vector}~(\ref{vector}) instead of \tcode{valarray} for that class; -\exitnote +\end{note} \item If \tcode{T} is a class, it does not overload unary \tcode{operator\&}. \end{itemize} @@ -134,7 +134,7 @@ or related function. \pnum -\enterexample +\begin{example} It is valid to instantiate \tcode{valarray}, but @@ -144,7 +144,7 @@ operands, since \tcode{complex} does not have any ordering operators. -\exitexample +\end{example} \rSec1[cfenv]{The floating-point environment} \rSec2[cfenv.syn]{Header \tcode{} synopsis} @@ -223,8 +223,8 @@ duration~(\ref{basic.stc.thread}). The initial state for a thread's floating-point environment is the state of the floating-point environment of the thread that constructs the corresponding \tcode{std::thread} object~(\ref{thread.thread.class}) at the time it -constructed the object. \enternote That is, the child thread gets the floating-point -state of the parent thread at the time of the child's creation. \exitnote +constructed the object. \begin{note} That is, the child thread gets the floating-point +state of the parent thread at the time of the child's creation. \end{note} \pnum A separate floating-point environment shall be maintained for each thread. Each function @@ -1396,7 +1396,7 @@ to types that satisfy the corresponding requirements, to objects instantiated from such types, and to templates producing such types when instantiated. -\enternote +\begin{note} These entities are specified in such a way as to permit the binding of any uniform random number generator object \tcode{e} @@ -1405,7 +1405,7 @@ thus producing a zero-argument function object such as given by \tcode{bind(d,e)}. -\exitnote +\end{note} \pnum \indextext{\idxcode{result_type}!entity characterization based on}% @@ -1568,12 +1568,12 @@ and produces a requested number of unsigned integer values $i$, $ 0 \le i < 2^{32} $, based on the consumed data. -\enternote +\begin{note} Such an object provides a mechanism to avoid replication of streams of random variates. This can be useful, for example, in applications requiring large numbers of random number engines. -\exitnote +\end{note} \pnum A class \tcode{S} @@ -1710,11 +1710,11 @@ in the range of possible results has (ideally) equal probability of being returned. -\enternote +\begin{note} The degree to which \tcode{g}'s results approximate the ideal is often determined statistically. -\exitnote +\end{note} \pnum A class \tcode{G} @@ -2782,10 +2782,10 @@ used throughout this section~\ref{rand.eng.lcong} \indextext{\idxcode{linear_congruential_engine}!modulus} is \tcode{numeric_limits\colcol{}max()} plus $1$. -\enternote +\begin{note} $m$ need not be representable as a value of type \tcode{result_type}. -\exitnote +\end{note} \pnum If the template parameter @@ -3069,7 +3069,7 @@ Set $c$ to 1 if $Y < 0$, otherwise set $c$ to 0. \end{enumeratea} -\enternote +\begin{note} This algorithm corresponds to a modular linear function of the form @@ -3077,7 +3077,7 @@ where $b$ is of the form $ m^r - m^s + 1 $ and $ a = b - (b-1) / m $. -\exitnote +\end{note} \pnum The generation algorithm% @@ -3397,11 +3397,11 @@ Otherwise let $ n = 1 + \left\lceil w / m \right\rceil $. \end{enumeratea} -\enternote +\begin{note} The relation $ w = n_0 w_0 + (n - n_0)(w_0 + 1) $ always holds. -\exitnote +\end{note} \pnum The transition algorithm% @@ -3773,7 +3773,7 @@ The choice of engine type named by this \tcode{typedef} is implementation-defined. -\enternote +\begin{note} The implementation may select this type on the basis of performance, @@ -3786,7 +3786,7 @@ may select different underlying engine types, code that uses this \tcode{typedef} need not generate identical sequences across implementations. -\exitnote +\end{note} \end{itemdescr}% \indextext{random number generation!predefined engines and adaptors|)}% \indextext{random number engine adaptor!with predefined parameters|)}% @@ -4163,14 +4163,14 @@ as specified below. \pnum -\enternote +\begin{note} Obtaining a value in this way can be a useful step in the process of transforming a value generated by a uniform random number generator into a value that can be delivered by a random number distribution. -\exitnote +\end{note} \indexlibrary{\idxcode{generate_canonical}}% \begin{itemdecl} @@ -4372,9 +4372,9 @@ p(x\,|\,a,b) = 1 / (b - a) \; \mbox{.} \] -\enternote +\begin{note} This implies that $p(x\,|\,a,b)$ is undefined when \tcode{a == b}. -\exitnote +\end{note} \begin{codeblock} template @@ -4716,9 +4716,9 @@ = \binom{k+i-1}{i} \cdot p^k \cdot (1-p)^i \; \mbox{.} \] -\enternote +\begin{note} This implies that $P(i\,|\,k,p)$ is undefined when \tcode{p == 1}. -\exitnote +\end{note} \begin{codeblock} template @@ -5870,9 +5870,9 @@ \pnum\effects Constructs a \tcode{discrete_distribution} object with $ n = 1 $ and $ p_0 = 1 $. - \enternote + \begin{note} Such an object will always deliver the value $0$. - \exitnote + \end{note} \end{itemdescr} @@ -7066,12 +7066,12 @@ \pnum \returns An object of class \tcode{valarray} containing those elements of the controlled sequence designated by \tcode{slicearr}. -\enterexample +\begin{example} \begin{codeblock} const valarray v0("abcdefghijklmnop", 16); // \tcode{v0[slice(2, 5, 3)]} returns \tcode{valarray("cfilo", 5)} \end{codeblock} -\exitexample +\end{example} \end{itemdescr} \indexlibrary{\idxcode{operator[]}!\idxcode{valarray}}% @@ -7082,14 +7082,14 @@ \begin{itemdescr} \pnum \returns An object that holds references to elements of the controlled -sequence selected by \tcode{slicearr}. \enterexample +sequence selected by \tcode{slicearr}. \begin{example} \begin{codeblock} valarray v0("abcdefghijklmnop", 16); valarray v1("ABCDE", 5); v0[slice(2, 5, 3)] = v1; // \tcode{v0 == valarray("abAdeBghCjkDmnEp", 16);} \end{codeblock} -\exitexample +\end{example} \end{itemdescr} \indexlibrary{\idxcode{operator[]}!\idxcode{valarray}}% @@ -7101,7 +7101,7 @@ \pnum \returns An object of class \tcode{valarray} containing those elements of the controlled sequence designated by \tcode{gslicearr}. -\enterexample +\begin{example} \begin{codeblock} const valarray v0("abcdefghijklmnop", 16); const size_t lv[] = { 2, 3 }; @@ -7110,7 +7110,7 @@ // \tcode{v0[gslice(3, len, str)]} returns // \tcode{valarray("dfhkmo", 6)} \end{codeblock} -\exitexample +\end{example} \end{itemdescr} \indexlibrary{\idxcode{operator[]}!\idxcode{valarray}}% @@ -7121,7 +7121,7 @@ \begin{itemdescr} \pnum \returns An object that holds references to elements of the controlled -sequence selected by \tcode{gslicearr}. \enterexample +sequence selected by \tcode{gslicearr}. \begin{example} \begin{codeblock} valarray v0("abcdefghijklmnop", 16); valarray v1("ABCDE", 5); @@ -7131,7 +7131,7 @@ v0[gslice(3, len, str)] = v1; // \tcode{v0 == valarray("abcAeBgCijDlEnFp", 16)} \end{codeblock} -\exitexample +\end{example} \end{itemdescr} \indexlibrary{\idxcode{operator[]}!\idxcode{valarray}}% @@ -7143,14 +7143,14 @@ \pnum \returns An object of class \tcode{valarray} containing those elements of the controlled sequence designated by \tcode{boolarr}. -\enterexample +\begin{example} \begin{codeblock} const valarray v0("abcdefghijklmnop", 16); const bool vb[] = { false, false, true, true, false, true }; // \tcode{v0[valarray(vb, 6)]} returns // \tcode{valarray("cdf", 3)} \end{codeblock} -\exitexample +\end{example} \end{itemdescr} \indexlibrary{\idxcode{operator[]}!\idxcode{valarray}}% @@ -7161,7 +7161,7 @@ \begin{itemdescr} \pnum \returns An object that holds references to elements of the controlled -sequence selected by \tcode{boolarr}. \enterexample +sequence selected by \tcode{boolarr}. \begin{example} \begin{codeblock} valarray v0("abcdefghijklmnop", 16); valarray v1("ABC", 3); @@ -7169,7 +7169,7 @@ v0[valarray(vb, 6)] = v1; // \tcode{v0 == valarray("abABeCghijklmnop", 16)} \end{codeblock} -\exitexample +\end{example} \end{itemdescr} \indexlibrary{\idxcode{operator[]}!\idxcode{valarray}}% @@ -7181,14 +7181,14 @@ \pnum \returns An object of class \tcode{valarray} containing those elements of the controlled sequence designated by \tcode{indarr}. -\enterexample +\begin{example} \begin{codeblock} const valarray v0("abcdefghijklmnop", 16); const size_t vi[] = { 7, 5, 2, 3, 8 }; // \tcode{v0[valarray(vi, 5)]} returns // \tcode{valarray("hfcdi", 5)} \end{codeblock} -\exitexample +\end{example} \end{itemdescr} \indexlibrary{\idxcode{operator[]}!\idxcode{valarray}}% @@ -7199,7 +7199,7 @@ \begin{itemdescr} \pnum \returns An object that holds references to elements of the controlled -sequence selected by \tcode{indarr}. \enterexample +sequence selected by \tcode{indarr}. \begin{example} \begin{codeblock} valarray v0("abcdefghijklmnop", 16); valarray v1("ABCDE", 5); @@ -7207,7 +7207,7 @@ v0[valarray(vi, 5)] = v1; // \tcode{v0 == valarray("abCDeBgAEjklmnop", 16)} \end{codeblock} -\exitexample +\end{example} \end{itemdescr} \rSec3[valarray.unary]{\tcode{valarray} unary operators} @@ -7455,11 +7455,11 @@ places, with zero fill. \pnum -\enterexample +\begin{example} If the argument has the value -2, the first two elements of the result will be value-initialized~(\ref{dcl.init}); the third element of the result will be assigned the value of the first element of the argument; etc. -\exitexample +\end{example} \end{itemdescr} \indexlibrary{\idxcode{cshift}!\idxcode{valarray}}% @@ -7839,10 +7839,10 @@ parameter. \pnum -\enterexample +\begin{example} \tcode{slice(3, 8, 2)} constructs a slice which selects elements 3, 5, 7, ... 17 from an array. -\exitexample +\end{example} \end{itemdescr} \rSec3[slice.access]{\tcode{slice} access functions} @@ -7913,7 +7913,7 @@ object. \pnum -\enterexample +\begin{example} The expression \tcode{a[slice(1, 5, 3)] = b;} has the effect of assigning the elements of @@ -7924,7 +7924,7 @@ selected from \tcode{a} are 1, 4, ..., 13. -\exitexample +\end{example} \rSec3[slice.arr.assign]{\tcode{slice_array} assignment} @@ -8045,7 +8045,7 @@ 0 to $l_{ij} - 1$. \pnum -\enterexample +\begin{example} The \tcode{gslice} specification @@ -8082,14 +8082,14 @@ \end{tabbing} That is, the highest-ordered index turns fastest. -\exitexample +\end{example} \pnum It is possible to have degenerate generalized slices in which an address is repeated. \pnum -\enterexample +\begin{example} If the stride parameters in the previous example are changed to \{1, 1, 1\}, the first few elements of the resulting sequence of indices will be @@ -8104,7 +8104,7 @@ \>$(0,\quad 1,\quad 2,\quad \ 6)$, \\ \>$\ldots$ \end{tabbing} -\exitexample +\end{example} \pnum If a degenerate slice is used as the argument to the @@ -8496,7 +8496,7 @@ \indextext{undefined}% \pnum -\enterexample +\begin{example} \begin{codeblock} int addr[] = {2, 3, 1, 4, 4}; valarray indirect(addr, 5); @@ -8505,7 +8505,7 @@ \end{codeblock} results in undefined behavior since element 4 is specified twice in the indirection. -\exitexample +\end{example} \end{itemdescr} \rSec3[indirect.array.comp.assign]{\tcode{indirect_array} computed assignment} @@ -9378,9 +9378,9 @@ and \tcode{}. \pnum -\enternote The overloads provided in C by type-generic macros are already +\begin{note} The overloads provided in C by type-generic macros are already provided in \tcode{} and \tcode{} by ``sufficient'' additional -overloads.\exitnote +overloads.\end{note} \pnum Tables~\ref{tab:numerics.hdr.cmath} and~\ref{tab:numerics.hdr.cstdlib} @@ -9531,11 +9531,11 @@ function has the semantics specified in the C standard, except that the implementation may specify that particular library functions may call \tcode{rand}. It is implementation-defined whether the \tcode{rand} function -may introduce data races~(\ref{res.on.data.races}). \enternote The random +may introduce data races~(\ref{res.on.data.races}). \begin{note} The random number generation~(\ref{rand}) facilities in this standard are often preferable to \tcode{rand}, because \tcode{rand}'s underlying algorithm is unspecified. Use of \tcode{rand} therefore continues to be nonportable, with unpredictable -and oft-questionable quality and performance. \exitnote +and oft-questionable quality and performance. \end{note} \pnum In addition to the @@ -9580,9 +9580,9 @@ for which \tcode{is_unsigned::value} is \tcode{true} and if \tcode{X} cannot be converted to \tcode{int} by integral promotion~(\ref{conv.prom}), the program is ill-formed. -\enternote +\begin{note} Arguments that can be promoted to \tcode{int} are permitted for compatibility with C. -\exitnote +\end{note} \pnum In addition to the diff --git a/source/overloading.tex b/source/overloading.tex index 8089b26674..491f5e4726 100644 --- a/source/overloading.tex +++ b/source/overloading.tex @@ -28,7 +28,7 @@ \term{overload resolution} and is defined in~\ref{over.match}. -\enterexample +\begin{example} \indextext{overloading!example of}% \begin{codeblock} @@ -38,7 +38,7 @@ abs(1); // calls \tcode{abs(int);} abs(1.0); // calls \tcode{abs(double);} \end{codeblock} -\exitexample +\end{example} \rSec1[over.load]{Overloadable declarations} \indextext{overloading!declarations}% @@ -50,7 +50,7 @@ overloaded are specified here. A program is ill-formed if it contains two such non-overloadable declarations in the same scope. -\enternote +\begin{note} This restriction applies to explicit declarations in a scope, and between such declarations and declarations made through a @@ -60,7 +60,7 @@ \grammarterm{using-directive}{s}) or overload resolution (e.g., for operator functions). -\exitnote +\end{note} \pnum Certain function declarations cannot be overloaded: @@ -92,7 +92,7 @@ declarations with the same name and the same parameter-type-list, then these member function declarations can be overloaded if they differ in the type of their implicit object parameter. -\enterexample +\begin{example} the following illustrates this distinction: \begin{codeblock} @@ -106,13 +106,13 @@ void g() const volatile; // OK: no static \tcode{g} }; \end{codeblock} -\exitexample +\end{example} \item Member function declarations with the same name and the same \grammarterm{parameter-type-list} as well as member function template declarations with the same name, the same \grammarterm{parameter-type-list}, and the same template parameter lists cannot be overloaded if any of them, but not -all, have a \grammarterm{ref-qualifier}~(\ref{dcl.fct}). \enterexample +all, have a \grammarterm{ref-qualifier}~(\ref{dcl.fct}). \begin{example} \begin{codeblock} class Y { @@ -124,14 +124,14 @@ // has a ref-qualifier }; \end{codeblock} -\exitexample +\end{example} \end{itemize} \pnum \indextext{equivalent~parameter~declarations}% \indextext{equivalent~parameter~declarations!overloading~and}% -\enternote +\begin{note} As specified in~\ref{dcl.fct}, function declarations that have equivalent parameter declarations declare the same function and therefore cannot @@ -145,7 +145,7 @@ A \tcode{typedef} is not a separate type, but only a synonym for another type~(\ref{dcl.typedef}). -\enterexample +\begin{example} \begin{codeblock} typedef int Int; @@ -156,13 +156,13 @@ void f(Int i) @\tcode{\{ /* ... */ \}}@ // error: redefinition of \tcode{f(int)} \end{codeblock} -\exitexample +\end{example} \indextext{\idxcode{enum}!overloading~and}% Enumerations, on the other hand, are distinct types and can be used to distinguish overloaded function declarations. -\enterexample +\begin{example} \begin{codeblock} enum E { a }; @@ -170,7 +170,7 @@ void f(int i) @\tcode{\{ /* ... */ \}}@ void f(E i) @\tcode{\{ /* ... */ \}}@ \end{codeblock} -\exitexample +\end{example} \item \indextext{overloading!array~versus~pointer}% @@ -184,7 +184,7 @@ declaration~(\ref{dcl.fct}). Only the second and subsequent array dimensions are significant in parameter types~(\ref{dcl.array}). -\enterexample +\begin{example} \begin{codeblock} int f(char*); @@ -197,7 +197,7 @@ int g(char[7][10]); // same as \tcode{g(char(*)[10]);} int g(char(*)[20]); // different from \tcode{g(char(*)[10]);} \end{codeblock} -\exitexample +\end{example} \item \indextext{overloading!function~versus~pointer}% @@ -205,7 +205,7 @@ Parameter declarations that differ only in that one is a function type and the other is a pointer to the same function type are equivalent. That is, the function type is adjusted to become a pointer to function type~(\ref{dcl.fct}). -\enterexample +\begin{example} \begin{codeblock} void h(int()); @@ -213,7 +213,7 @@ void h(int x()) { } // definition of \tcode{h(int())} void h(int (*x)()) { } // ill-formed: redefinition of \tcode{h(int())} \end{codeblock} -\exitexample +\end{example} \item \indextext{\idxcode{const}!overloading~and}% @@ -231,7 +231,7 @@ each parameter type are ignored when determining which function is being declared, defined, or called. -\enterexample +\begin{example} \begin{codeblock} typedef const int cInt; @@ -241,7 +241,7 @@ int f (int) @\tcode{\{ /* ... */ \}}@ // definition of \tcode{f(int)} int f (cInt) @\tcode{\{ /* ... */ \}}@ // error: redefinition of \tcode{f(int)} \end{codeblock} -\exitexample +\end{example} Only the \tcode{const} @@ -286,7 +286,7 @@ \indextext{default~initializers!overloading~and}% Two parameter declarations that differ only in their default arguments are equivalent. -\enterexample +\begin{example} consider the following: \begin{codeblock} @@ -301,9 +301,9 @@ f (); // Error: \tcode{f(int, int)} or \tcode{f()}? } \end{codeblock} -\exitexample -\exitnote +\end{example} \end{itemize} +\end{note} \rSec1[over.dcl]{Declaration matching}% \indextext{overloading!declaration matching}% @@ -316,7 +316,7 @@ A function member of a derived class is \textit{not} in the same scope as a function member of the same name in a base class. -\enterexample +\begin{example} \begin{codeblock} struct B { @@ -345,12 +345,12 @@ pd->f("Ben"); // OK, calls \tcode{D::f} } \end{codeblock} -\exitexample +\end{example} \pnum A locally declared function is not in the same scope as a function in a containing scope. -\enterexample +\begin{example} \begin{codeblock} void f(const char*); @@ -368,14 +368,14 @@ } } \end{codeblock} -\exitexample +\end{example} \pnum \indextext{access control!overloading and}% \indextext{overloading!access control and}% Different versions of an overloaded member function can be given different access rules. -\enterexample +\begin{example} \begin{codeblock} class buffer { @@ -388,7 +388,7 @@ buffer(int s) { p = new char[size = s]; } }; \end{codeblock} -\exitexample +\end{example} \rSec1[over.match]{Overload resolution}% \indextext{overloading!resolution|(}% @@ -409,13 +409,13 @@ how well (for non-static member functions) the object matches the implicit object parameter, and certain other properties of the candidate function. -\enternote +\begin{note} The function selected by overload resolution is not guaranteed to be appropriate for the context. Other restrictions, such as the accessibility of the function, can make its use in the calling context ill-formed. -\exitnote +\end{note} \pnum \indextext{overloading!resolution!contexts}% @@ -539,7 +539,7 @@ \textit{cv} is the cv-qualification on the member function declaration. -\enterexample +\begin{example} for a \tcode{const} member @@ -548,7 +548,7 @@ the extra parameter is assumed to have type ``reference to \tcode{const X}''. -\exitexample +\end{example} For conversion functions, the function is considered to be a member of the class of the implied object argument for the purpose of defining the type of the implicit object parameter. @@ -561,11 +561,11 @@ For static member functions, the implicit object parameter is considered to match any object (since if the function is selected, the object is discarded). -\enternote +\begin{note} No actual type is established for the implicit object parameter of a static member function, and no attempt will be made to determine a conversion sequence for that parameter~(\ref{over.match.best}). -\exitnote +\end{note} \pnum \indextext{implied object argument!implicit conversion sequences}% @@ -595,9 +595,9 @@ an rvalue can be bound to the parameter as long as in all other respects the argument can be converted to the type of the implicit object parameter. -\enternote The fact that such an argument is an rvalue does not +\begin{note} The fact that such an argument is an rvalue does not affect the ranking of implicit conversion sequences~(\ref{over.ics.rank}). -\exitnote +\end{note} \end{itemize} \pnum @@ -607,7 +607,7 @@ implicit conversion sequence, special rules apply when selecting the best user-defined conversion~(\ref{over.match.best}, \ref{over.best.ics}). -\enterexample +\begin{example} \begin{codeblock} class T { @@ -621,7 +621,7 @@ }; T a = 1; // ill-formed: \tcode{T(C(1))} not tried \end{codeblock} -\exitexample +\end{example} \pnum In each case where a candidate is a function template, candidate @@ -671,8 +671,8 @@ If the \grammarterm{postfix-expression} denotes the address of a set of overloaded functions and/or function templates, overload resolution is applied using that set as described above. If the function selected by overload resolution is a non-static member -function, the program is ill-formed. \enternote The resolution of the address of an -overload set in other contexts is described in \ref{over.over}. \exitnote +function, the program is ill-formed. \begin{note} The resolution of the address of an +overload set in other contexts is described in \ref{over.over}. \end{note} \rSec4[over.call.func]{Call to named function} @@ -885,7 +885,7 @@ the argument expressions present in the function call syntax preceded by the implied object argument \tcode{(E)}. -\enternote +\begin{note} When comparing the call against the function call operators, the implied object argument is compared against the implicit object parameter of the @@ -899,8 +899,8 @@ parameter since it converts the implied object argument to the appropriate function pointer or reference required by that first parameter. -\exitnote -\enterexample +\end{note} +\begin{example} \begin{codeblock} int f1(int); @@ -914,7 +914,7 @@ int i = a(1); // calls \tcode{f1} via pointer returned from // conversion function \end{codeblock} -\exitexample% +\end{example}% \indextext{overloading!resolution!function call syntax|)} \rSec3[over.match.oper]{Operators in expressions}% @@ -924,7 +924,7 @@ If no operand of an operator in an expression has a type that is a class or an enumeration, the operator is assumed to be a built-in operator and interpreted according to Clause~\ref{expr}. -\enternote +\begin{note} Because \tcode{.}, \tcode{.*}, @@ -937,8 +937,8 @@ cannot be overloaded, but the rules in this subclause are used to determine the conversions to be applied to the second and third operands when they have class or enumeration type~(\ref{expr.cond}). -\exitnote -\enterexample +\end{note} +\begin{example} \begin{codeblock} struct String { @@ -956,7 +956,7 @@ // would perform the operation. } \end{codeblock} -\exitexample +\end{example} \pnum If either operand has a type that is a class or an enumeration, a @@ -1083,7 +1083,7 @@ according to~\ref{over.match.viable} and~\ref{over.match.best}.\footnote{If the set of candidate functions is empty, overload resolution is unsuccessful.} -\enterexample +\begin{example} \begin{codeblock} struct A { @@ -1095,7 +1095,7 @@ a + b; // \tcode{operator+(a,b)} chosen over \tcode{int(a) + int(b)} } \end{codeblock} -\exitexample +\end{example} % USA _136/_28 L6899 USA core-756/734/682 over.match.oper \pnum @@ -1105,7 +1105,7 @@ sequence of a user-defined conversion sequence~(\ref{over.ics.user}) is not applied. Then the operator is treated as the corresponding built-in operator and interpreted according to Clause~\ref{expr}. -\enterexample +\begin{example} \begin{codeblock} struct X { operator double(); @@ -1118,7 +1118,7 @@ int *a = Y() + 100.0; // error: pointer arithmetic requires integral operand int *b = Y() + X(); // error: pointer arithmetic requires integral operand \end{codeblock} -\exitexample +\end{example} \pnum The second operand of operator @@ -1154,7 +1154,7 @@ Clause~\ref{expr}. \pnum -\enternote +\begin{note} The lookup rules for operators in expressions are different than the lookup rules for operator function names in a function call, as shown in the following @@ -1176,7 +1176,7 @@ a + a; // OK: calls global \tcode{operator+} } \end{codeblock} -\exitnote +\end{note} \rSec3[over.match.ctor]{Initialization by constructor}% \indextext{overloading!resolution!initialization} @@ -1208,9 +1208,9 @@ type of the object being initialized. Overload resolution is used to select the user-defined conversion to be invoked. -\enternote The conversion performed for indirect binding to a reference to a possibly +\begin{note} The conversion performed for indirect binding to a reference to a possibly cv-qualified class type is determined in terms of a corresponding non-reference -copy-initialization. \exitnote +copy-initialization. \end{note} Assuming that ``\textit{cv1} \tcode{T}'' is the type of the object being initialized, with \tcode{T} @@ -1256,11 +1256,11 @@ \pnum In both cases, the argument list has one argument, which is the initializer expression. -\enternote +\begin{note} This argument will be compared against the first parameter of the constructors and against the implicit object parameter of the conversion functions. -\exitnote +\end{note} \rSec3[over.match.conv]{Initialization by conversion function}% \indextext{overloading!resolution!initialization} @@ -1316,10 +1316,10 @@ \pnum The argument list has one argument, which is the initializer expression. -\enternote +\begin{note} This argument will be compared against the implicit object parameter of the conversion functions. -\exitnote +\end{note} \rSec3[over.match.ref]{Initialization by conversion function for direct reference binding}% \indextext{overloading!resolution!initialization} @@ -1363,10 +1363,10 @@ \pnum The argument list has one argument, which is the initializer expression. -\enternote +\begin{note} This argument will be compared against the implicit object parameter of the conversion functions. -\exitnote +\end{note} \rSec3[over.match.list]{Initialization by list-initialization}% \indextext{overloading!resolution!initialization} @@ -1395,12 +1395,12 @@ If the initializer list has no elements and \tcode{T} has a default constructor, the first phase is omitted. In copy-list-initialization, if an \tcode{explicit} constructor is -chosen, the initialization is ill-formed. \enternote +chosen, the initialization is ill-formed. \begin{note} This differs from other situations (\ref{over.match.ctor},~\ref{over.match.copy}), where only converting constructors are considered for copy-initialization. This restriction only applies if this initialization is part of the final result of overload -resolution. \exitnote +resolution. \end{note} \rSec2[over.match.viable]{Viable functions}% \indextext{overloading!resolution!viable functions|(} @@ -1535,7 +1535,7 @@ from the return type of \tcode{F2} to the destination type. -\enterexample +\begin{example} \begin{codeblock} struct A { @@ -1549,14 +1549,14 @@ float x = a; // ambiguous: both possibilities require conversions, // and neither is better than the other \end{codeblock} -\exitexample +\end{example} or, if not that, \item the context is an initialization by conversion function for direct reference binding (\ref{over.match.ref}) of a reference to function type, the return type of \tcode{F1} is the same kind of reference (i.e. lvalue or rvalue) as the reference being initialized, and the return type of \tcode{F2} is not -\enterexample +\begin{example} \begin{codeblock} template struct A { @@ -1569,7 +1569,7 @@ Fn&& rf = a; // calls \#2 \end{codeblock} -\exitexample +\end{example} or, if not that, \item @@ -1633,7 +1633,7 @@ \tcode{W} is better than all other functions.}. -\enterexample +\begin{example} \begin{codeblock} void Fcn(const int*, short); @@ -1656,7 +1656,7 @@ // and \tcode{c} $\to$ \tcode{int} is better than \tcode{c} $\to$ \tcode{short} } \end{codeblock} -\exitexample +\end{example} \pnum If the best viable function resolves to a function for @@ -1666,7 +1666,7 @@ \grammarterm{using-declaration}{s} --- specify a default argument that made the function viable, the program is ill-formed. -\enterexample +\begin{example} \begin{codeblock} namespace A { @@ -1684,7 +1684,7 @@ f(); // Error: found default argument twice } \end{codeblock} -\exitexample +\end{example} \rSec3[over.best.ics]{Implicit conversion sequences}% \indextext{overloading!resolution!implicit conversions and|(} @@ -1746,11 +1746,11 @@ (in all cases), \end{itemize} user-defined conversion sequences are not considered. -\enternote +\begin{note} These rules prevent more than one user-defined conversion from being applied during overload resolution, thereby avoiding infinite recursion. -\exitnote -\enterexample +\end{note} +\begin{example} \begin{codeblock} struct Y { Y(int); }; struct A { operator int(); }; @@ -1761,7 +1761,7 @@ B b; X x({b}); // error: \tcode{B::operator X()} is not a candidate \end{codeblock} -\exitexample +\end{example} \pnum For the case where the parameter type is a reference, see~\ref{over.ics.ref}. @@ -1773,14 +1773,14 @@ The implicit conversion sequence is the one required to convert the argument expression to a prvalue of the type of the parameter. -\enternote +\begin{note} When the parameter has a class type, this is a conceptual conversion defined for the purposes of Clause~\ref{over}; the actual initialization is defined in terms of constructors and is not a conversion. -\exitnote +\end{note} Any difference in top-level cv-qualification is subsumed by the initialization itself and does not constitute a conversion. -\enterexample +\begin{example} a parameter of type \tcode{A} can be initialized from an argument of type @@ -1790,7 +1790,7 @@ \tcode{const A} to \tcode{A}. -\exitexample +\end{example} When the parameter has a class type and the argument expression has the same type, the implicit conversion sequence is an identity conversion. When the parameter has a class type and the argument expression has a @@ -1798,10 +1798,10 @@ derived-to-base \indextext{conversion!derived-to-base}% Conversion from the derived class to the base class. -\enternote +\begin{note} There is no such standard conversion; this derived-to-base Conversion exists only in the description of implicit conversion sequences. -\exitnote +\end{note} A derived-to-base Conversion has Conversion rank~(\ref{over.ics.scs}). \pnum @@ -1894,7 +1894,7 @@ summarizes the conversions defined in Clause~\ref{conv} and partitions them into four disjoint categories: Lvalue Transformation, Qualification Adjustment, Promotion, and Conversion. -\enternote +\begin{note} These categories are orthogonal with respect to value category, cv-qualification, and data representation: the Lvalue Transformations do not change the cv-qualification or data @@ -1902,10 +1902,10 @@ change the value category or data representation of the type; and the Promotions and Conversions do not change the value category or cv-qualification of the type. -\exitnote +\end{note} \pnum -\enternote +\begin{note} As described in Clause~\ref{conv}, a standard conversion sequence is either the Identity conversion by itself (that is, no conversion) or consists of one to three @@ -1918,7 +1918,7 @@ or \textbf{Conversion}, \textbf{Qualification Adjustment}. -\exitnote +\end{note} \pnum \indextext{conversion rank}% @@ -2009,7 +2009,7 @@ unless the argument expression has a type that is a derived class of the parameter type, in which case the implicit conversion sequence is a derived-to-base Conversion~(\ref{over.best.ics}). -\enterexample +\begin{example} \begin{codeblock} struct A {}; @@ -2019,7 +2019,7 @@ int i = f(b); // calls \tcode{f(B\&)}, an exact match, rather than // \tcode{f(A\&)}, a conversion \end{codeblock} -\exitexample +\end{example} If the parameter binds directly to the result of applying a conversion function to the argument expression, the implicit conversion sequence is a user-defined conversion sequence~(\ref{over.ics.user}), @@ -2044,20 +2044,20 @@ other than a reference to a non-volatile \tcode{const} type to an rvalue or binding an rvalue reference to an lvalue other than a function lvalue. -\enternote +\begin{note} This means, for example, that a candidate function cannot be a viable function if it has a non-\tcode{const} lvalue reference parameter (other than the implicit object parameter) and the corresponding argument is a temporary or would require one to be created to initialize the lvalue reference (see~\ref{dcl.init.ref}). -\exitnote +\end{note} \pnum Other restrictions on binding a reference to a particular argument that are not based on the types of the reference and the argument do not affect the formation of a standard conversion sequence, however. -\enterexample +\begin{example} a function with an ``lvalue reference to \tcode{int}'' parameter can be a viable candidate even if the corresponding argument is an \tcode{int} @@ -2072,7 +2072,7 @@ If the function is selected by overload resolution, the call will nonetheless be ill-formed because of the prohibition on binding a non-\tcode{const} lvalue reference to a bit-field~(\ref{dcl.init.ref}). -\exitexample +\end{example} \rSec4[over.ics.list]{List-initialization sequence} @@ -2101,7 +2101,7 @@ conversion sequence is the worst conversion necessary to convert an element of the list to \tcode{X}, or if the initializer list has no elements, the identity conversion. This conversion can be a user-defined conversion even in -the context of a call to an initializer-list constructor. \enterexample +the context of a call to an initializer-list constructor. \begin{example} \begin{codeblock} void f(std::initializer_list); f( {} ); // OK: \tcode{f(initializer_list)} identity conversion @@ -2123,7 +2123,7 @@ void h(const IA&); h({ 1, 2, 3 }); // OK: identity conversion \end{codeblock} -\exitexample +\end{example} \pnum Otherwise, if the parameter type is ``array of \tcode{N} \tcode{X}'', @@ -2142,7 +2142,7 @@ the others, the implicit conversion sequence is the ambiguous conversion sequence. User-defined conversions are allowed for conversion of the initializer list elements to the constructor parameter types except as noted -in~\ref{over.best.ics}. \enterexample +in~\ref{over.best.ics}. \begin{example} \begin{codeblock} struct A { A(std::initializer_list); @@ -2172,14 +2172,14 @@ void i(D); i({ {1,2}, {"bar"} }); // OK: \tcode{i(D(A(std::initializer_list\{1,2\}),C(std::string("bar"))))} \end{codeblock} -\exitexample +\end{example} \pnum Otherwise, if the parameter has an aggregate type which can be initialized from the initializer list according to the rules for aggregate initialization~(\ref{dcl.init.aggr}), the implicit conversion sequence is a user-defined conversion sequence with the second standard conversion -sequence an identity conversion. \enterexample +sequence an identity conversion. \begin{example} \begin{codeblock} struct A { int m1; @@ -2190,12 +2190,12 @@ f( {'a', 'b'} ); // OK: \tcode{f(A(int,double))} user-defined conversion f( {1.0} ); // error: narrowing \end{codeblock} -\exitexample +\end{example} \pnum -Otherwise, if the parameter is a reference, see~\ref{over.ics.ref}. \enternote +Otherwise, if the parameter is a reference, see~\ref{over.ics.ref}. \begin{note} The rules in this section will apply for initializing the underlying temporary -for the reference. \exitnote \enterexample +for the reference. \end{note} \begin{example} \begin{codeblock} struct A { int m1; @@ -2209,7 +2209,7 @@ void g(const double &); g({1}); // same conversion as \tcode{int} to \tcode{double} \end{codeblock} -\exitexample +\end{example} \pnum Otherwise, if the parameter type is not a class: @@ -2217,21 +2217,21 @@ \begin{itemize} \item if the initializer list has one element that is not itself an initializer list, the implicit conversion sequence is the one required to convert the element to -the parameter type; \enterexample +the parameter type; \begin{example} \begin{codeblock} void f(int); f( {'a'} ); // OK: same conversion as \tcode{char} to \tcode{int} f( {1.0} ); // error: narrowing \end{codeblock} -\exitexample +\end{example} \item if the initializer list has no elements, the implicit conversion sequence -is the identity conversion. \enterexample +is the identity conversion. \begin{example} \begin{codeblock} void f(int); f( { } ); // OK: identity conversion \end{codeblock} -\exitexample +\end{example} \end{itemize} \pnum @@ -2290,7 +2290,7 @@ type ``array of \tcode{N2} \tcode{T}'', and \tcode{N1} is smaller than \tcode{N2}, \end{itemize} even if one of the other rules in this paragraph would otherwise apply. -\enterexample +\begin{example} \begin{codeblock} void f1(int); // \#1 void f1(std::initializer_list); // \#2 @@ -2300,7 +2300,7 @@ void f2(std::initializer_list); // \#4 void g2() { f2({"foo","bar"}); } // chooses \#4 \end{codeblock} -\exitexample +\end{example} \item Standard conversion sequence @@ -2340,7 +2340,7 @@ and \tcode{S1} binds an rvalue reference to an rvalue and \tcode{S2} binds an lvalue reference. -\enterexample +\begin{example} \begin{codeblock} int i; int f1(); @@ -2365,20 +2365,20 @@ A().p(); // calls \tcode{A::p()\&\&} a.p(); // calls \tcode{A::p()\&} \end{codeblock} -\exitexample +\end{example} or, if not that, \item \tcode{S1} and \tcode{S2} are reference bindings~(\ref{dcl.init.ref}) and \tcode{S1} binds an lvalue reference to a function lvalue and \tcode{S2} binds -an rvalue reference to a function lvalue. \enterexample +an rvalue reference to a function lvalue. \begin{example} \begin{codeblock} int f(void(&)()); // \#1 int f(void(&&)()); // \#2 void g(); int i1 = f(g); // calls \#1 \end{codeblock} -\exitexample +\end{example} or, if not that, \item @@ -2392,7 +2392,7 @@ \tcode{T1} is a proper subset of the cv-qualification signature of type \tcode{T2}. -\enterexample +\begin{example} \begin{codeblock} int f(const volatile int *); @@ -2400,7 +2400,7 @@ int i; int j = f(&i); // calls \tcode{f(const int*)} \end{codeblock} -\exitexample +\end{example} or, if not that, \item @@ -2414,7 +2414,7 @@ refers is more cv-qualified than the type to which the reference initialized by \tcode{S1} refers. -\enterexample +\begin{example} \begin{codeblock} int f(const int &); @@ -2435,7 +2435,7 @@ b.f(); // calls \tcode{X::f()} } \end{codeblock} -\exitexample +\end{example} \end{itemize} \item @@ -2452,7 +2452,7 @@ is better than the second standard conversion sequence of \tcode{U2}. -\enterexample +\begin{example} \begin{codeblock} struct A { @@ -2463,7 +2463,7 @@ int i = f(a); // calls \tcode{f(int)}, because \tcode{short} $\to$ \tcode{int} is // better than \tcode{short} $\to$ \tcode{float}. \end{codeblock} -\exitexample +\end{example} \end{itemize} @@ -2529,7 +2529,7 @@ \tcode{C*} to \tcode{A*}, -\enterexample +\begin{example} \begin{codeblock} struct A {}; @@ -2540,7 +2540,7 @@ int f(B*); int i = f(pc); // calls \tcode{f(B*)} \end{codeblock} -\exitexample +\end{example} \item binding of an expression of type @@ -2610,13 +2610,13 @@ \tcode{A}. \end{itemize} -\enternote +\begin{note} Compared conversion sequences will have different source types only in the context of comparing the second standard conversion sequence of an initialization by user-defined conversion (see~\ref{over.match.best}); in all other contexts, the source types will be the same and the target types will be different. -\exitnote +\end{note} \end{itemize}% \indextext{overloading!resolution!implicit conversions and|)}% \indextext{overloading!resolution|)} @@ -2635,10 +2635,10 @@ of the target type required in the context if \tcode{F} (after possibly applying the function pointer conversion~(\ref{conv.fctptr})) is identical to \tcode{FT}. -\enternote +\begin{note} That is, the class of which the function is a member is ignored when matching a pointer-to-member-function type. -\exitnote +\end{note} The target can be \begin{itemize} @@ -2666,10 +2666,10 @@ operator. An overloaded function name shall not be used without arguments in contexts other than those listed. -\enternote +\begin{note} Any redundant set of parentheses surrounding the overloaded function name is ignored~(\ref{expr.prim}). -\exitnote +\end{note} \pnum If the name is a function template, template argument deduction is @@ -2680,7 +2680,7 @@ function template specialization, which is added to the set of overloaded functions considered. -\enternote +\begin{note} As described in~\ref{temp.arg.explicit}, if deduction fails and the function template name is followed by an explicit template argument list, the @@ -2690,7 +2690,7 @@ \grammarterm{template-id} is considered to be an lvalue for that function template specialization. The target type is not used in that determination. -\exitnote +\end{note} \pnum Non-member functions and static member functions @@ -2722,7 +2722,7 @@ if any, there shall remain exactly one selected function. \pnum -\enterexample +\begin{example} \begin{codeblock} int f(double); int f(int); @@ -2759,10 +2759,10 @@ // pointer to member int (*p6)(long) = &(X::f); // OK \end{codeblock} -\exitexample +\end{example} \pnum -\enternote +\begin{note} If \tcode{f()} and @@ -2773,11 +2773,11 @@ \tcode{f(\&g)}, or the equivalent expression \tcode{f(g)}. -\exitnote +\end{note} \pnum \indextext{conversion!overload resolution and pointer}% -\enternote +\begin{note} Even if \tcode{B} is a public base of \tcode{D}, we have @@ -2788,7 +2788,7 @@ void g(D*); void (*p2)(B*) = &g; // error \end{codeblock} -\exitnote +\end{note} \rSec1[over.oper]{Overloaded operators}% \indextext{overloading!operator|(}% @@ -2826,7 +2826,7 @@ \>(\,)\>[\,] \end{bnfkeywordtab} -\enternote +\begin{note} The last two operators are function call~(\ref{expr.call}) and subscripting~(\ref{expr.sub}). The operators @@ -2836,7 +2836,7 @@ and \tcode{[]} are formed from more than one token. -\exitnote +\end{note} \indextext{operator!subscripting}% \indextext{operator!function~call}% @@ -2870,13 +2870,13 @@ They can be explicitly called, however, using the \grammarterm{operator-function-id} as the name of the function in the function call syntax~(\ref{expr.call}). -\enterexample +\begin{example} \begin{codeblock} complex z = a.operator+(b); // \tcode{complex z = a+b;} void* p = operator new(sizeof(int)*n); \end{codeblock} -\exitexample +\end{example} \pnum The allocation and deallocation functions, @@ -2970,10 +2970,10 @@ \pnum The unary and binary forms of the same operator are considered to have the same name. -\enternote +\begin{note} Consequently, a unary operator can hide a binary operator from an enclosing scope, and vice versa. -\exitnote +\end{note} \rSec2[over.binary]{Binary operators}% \indextext{binary operator!overloaded}% @@ -3011,7 +3011,7 @@ \pnum Any assignment operator, even the copy and move assignment operators, can be virtual. -\enternote +\begin{note} For a derived class \tcode{D} with a base class @@ -3022,7 +3022,7 @@ does not override \tcode{B}'s virtual copy/move assignment operator. -\enterexample +\begin{example} \begin{codeblock} struct B { @@ -3046,8 +3046,8 @@ // \tcode{D::operator=(const D\&)} } \end{codeblock} -\exitexample -\exitnote +\end{example} +\end{note} \rSec2[over.call]{Function call}% \indextext{function~call~operator!overloaded}% @@ -3111,7 +3111,7 @@ \tcode{T::op\-er\-a\-tor[]\-(T1)} exists and if the operator is selected as the best match function by the overload resolution mechanism~(\ref{over.match.best}). -\enterexample +\begin{example} \begin{codeblock} struct X { Z operator[](std::initializer_list); @@ -3121,7 +3121,7 @@ int a[10]; a[{1,2,3}] = 7; // error: built-in subscript operator \end{codeblock} -\exitexample +\end{example} \rSec2[over.ref]{Class member access} \indextext{member access operator!overloaded}% @@ -3188,7 +3188,7 @@ \tcode{operator++} is \tcode{2}.} -\enterexample +\begin{example} \begin{codeblock} struct X { @@ -3212,7 +3212,7 @@ operator++(b, 0); // explicit call: like \tcode{b++;} } \end{codeblock} -\exitexample +\end{example} \pnum The prefix and postfix decrement operators @@ -3287,17 +3287,17 @@ Literal operators and literal operator templates shall not have C language linkage. \pnum -\enternote Literal operators and literal operator templates are usually invoked +\begin{note} Literal operators and literal operator templates are usually invoked implicitly through user-defined literals~(\ref{lex.ext}). However, except for the constraints described above, they are ordinary namespace-scope functions and function templates. In particular, they are looked up like ordinary functions and function templates and they follow the same overload resolution rules. Also, they can be declared \tcode{inline} or \tcode{constexpr}, they may have internal or external linkage, they can be called explicitly, their addresses can be -taken, etc. \exitnote +taken, etc. \end{note} \pnum -\enterexample +\begin{example} \begin{codeblock} void operator "" _km(long double); // OK string operator "" _i18n(const char*, std::size_t); // OK @@ -3312,7 +3312,7 @@ template int operator "" _j(const char*); // error: invalid \grammarterm{parameter-declaration-clause} extern "C" void operator "" _m(long double); // error: C language linkage \end{codeblock} -\exitexample% +\end{example}% \indextext{overloading!operator|)} \rSec1[over.built]{Built-in operators}% @@ -3324,7 +3324,7 @@ These candidate functions participate in the operator overload resolution process as described in~\ref{over.match.oper} and are used for no other purpose. -\enternote +\begin{note} Because built-in operators take only operands with non-class type, and operator overload resolution occurs only when an operand expression originally has class or enumeration type, @@ -3344,7 +3344,7 @@ candidate with the same name and parameter types as a built-in candidate operator function, the built-in operator function is hidden and is not included in the set of candidate functions. -\exitnote +\end{note} \pnum In this subclause, the term @@ -3359,11 +3359,11 @@ Similarly, the term \term{promoted arithmetic type} refers to floating types plus promoted integral types. -\enternote +\begin{note} In all cases where a promoted integral type or promoted arithmetic type is required, an operand of enumeration type will be acceptable by way of the integral promotions. -\exitnote +\end{note} \pnum For every pair @@ -3719,13 +3719,13 @@ \term{L} and \term{R}. -\enternote +\begin{note} As with all these descriptions of candidate functions, this declaration serves only to describe the built-in operator for purposes of overload resolution. The operator ``\tcode{?:}'' cannot be overloaded. -\exitnote +\end{note} \pnum For every type diff --git a/source/preprocessor.tex b/source/preprocessor.tex index 5814894b68..41ebe88459 100644 --- a/source/preprocessor.tex +++ b/source/preprocessor.tex @@ -172,7 +172,7 @@ The preprocessing tokens within a preprocessing directive are not subject to macro expansion unless otherwise stated. -\enterexample In: +\begin{example} In: \begin{codeblock} #define EMPTY @@ -182,7 +182,7 @@ the sequence of preprocessing tokens on the second line is \textit{not} a preprocessing directive, because it does not begin with a \# at the start of translation phase 4, even though it will do so after the macro \tcode{EMPTY} -has been replaced.\exitexample +has been replaced.\end{example} \rSec1[cpp.cond]{Conditional inclusion}% \indextext{preprocessing directive!conditional inclusion}% @@ -411,7 +411,7 @@ comments may appear anywhere in a source file, including within a preprocessing directive.} -\enterexample +\begin{example} This demonstrates a way to include a library \tcode{optional} facility only if it is available: @@ -427,7 +427,7 @@ # define have_optional 0 #endif \end{codeblock} -\exitexample +\end{example} \rSec1[cpp.include]{Source file inclusion} \indextext{preprocessing directives!header inclusion} @@ -542,7 +542,7 @@ up to an \impldef{nesting limit for \tcode{\#include} directives} nesting limit. \pnum -\enternote +\begin{note} Although an implementation may provide a mechanism for making arbitrary source files available to the \tcode{< >} search, in general programmers should use the \tcode{< >} form for headers provided @@ -556,10 +556,10 @@ #include "myprog.h" \end{codeblock} -\exitnote +\end{note} \pnum -\enterexample +\begin{example} This illustrates macro-replaced \tcode{\#include} directives: @@ -574,7 +574,7 @@ #endif #include INCFILE \end{codeblock} -\exitexample +\end{example} \rSec1[cpp.replace]{Macro replacement}% \indextext{macro!replacement|(}% @@ -854,7 +854,7 @@ \tcode{\#\#} operators is unspecified. -\enterexample In the following fragment: +\begin{example} In the following fragment: \begin{codeblock} #define hash_hash # ## # @@ -877,7 +877,7 @@ In other words, expanding \tcode{hash_hash} produces a new token, consisting of two adjacent sharp signs, but this new token is not the -\tcode{\#\#} operator. \exitexample +\tcode{\#\#} operator. \end{example} \rSec2[cpp.rescan]{Rescanning and further replacement}% \indextext{macro!rescanning and replacement}% @@ -936,17 +936,17 @@ a macro name. \pnum -\enterexample +\begin{example} The simplest use of this facility is to define a ``manifest constant,'' as in \begin{codeblock} #define TABSIZE 100 int table[TABSIZE]; \end{codeblock} -\exitexample +\end{example} \pnum -\enterexample +\begin{example} The following defines a function-like macro whose value is the maximum of its arguments. It has the advantages of working for any compatible types of the arguments @@ -966,10 +966,10 @@ The parentheses ensure that the arguments and the resulting expression are bound properly. -\exitexample +\end{example} \pnum -\enterexample +\begin{example} To illustrate the rules for redefinition and reexamination, the sequence @@ -1004,10 +1004,10 @@ int i[] = { 1, 23, 4, 5, }; char c[2][6] = { "hello", "" }; \end{codeblock} -\exitexample +\end{example} \pnum -\enterexample +\begin{example} To illustrate the rules for creating character string literals and concatenating tokens, the sequence @@ -1056,10 +1056,10 @@ and \tcode{\#\#} tokens in the macro definition is optional. -\exitexample +\end{example} \pnum -\enterexample +\begin{example} To illustrate the rules for placemarker preprocessing tokens, the sequence \begin{codeblock} @@ -1074,10 +1074,10 @@ int j[] = { 123, 45, 67, 89, 10, 11, 12, }; \end{codeblock} -\exitexample +\end{example} \pnum -\enterexample +\begin{example} To demonstrate the redefinition rules, the following sequence is valid. @@ -1098,10 +1098,10 @@ #define FUNC_LIKE(b) ( a ) // different parameter usage #define FUNC_LIKE(b) ( b ) // different parameter spelling \end{codeblock} -\exitexample +\end{example} \pnum -\enterexample +\begin{example} Finally, to show the variable argument list macro facilities: \begin{codeblock} @@ -1123,7 +1123,7 @@ ((x>y) ? puts("x>y") : printf("x is %d but y is %d", x, y)); \end{codeblock} -\exitexample +\end{example} \indextext{macro!replacement|)} \rSec1[cpp.line]{Line control}% @@ -1388,7 +1388,7 @@ \grammarterm{pp-tokens} in a pragma directive. The original four preprocessing tokens in the unary operator expression are removed. -\enterexample +\begin{example} \begin{codeblock} #pragma listing on "..\listing.dir" @@ -1410,5 +1410,5 @@ LISTING( ..\listing.dir ) \end{codeblock} -\exitexample% +\end{example}% \indextext{preprocessing directives|)} diff --git a/source/regex.tex b/source/regex.tex index da8c1198eb..5ae75ab825 100644 --- a/source/regex.tex +++ b/source/regex.tex @@ -84,9 +84,9 @@ \pnum This subclause defines requirements on classes representing regular -expression traits. \enternote The class template +expression traits. \begin{note} The class template \tcode{regex_traits}, defined in Clause~\ref{re.traits}, -satisfies these requirements. \exitnote +satisfies these requirements. \end{note} \pnum The class template \tcode{basic_regex}, defined in @@ -229,8 +229,8 @@ & \tcode{int} & Returns the value represented by the digit \textit{c} in base \textit{I} if the character \textit{c} is a valid digit in base \textit{I}; - otherwise returns \tcode{-1}. \enternote The value of \textit{I} will only - be 8, 10, or 16. \exitnote + otherwise returns \tcode{-1}. \begin{note} The value of \textit{I} will only + be 8, 10, or 16. \end{note} \\ \rowsep \tcode{u.imbue(loc)} & \tcode{X::locale_type} @@ -244,12 +244,12 @@ \end{libreqtab3} \pnum -\enternote +\begin{note} Class template \tcode{regex_traits} satisfies the requirements for a regular expression traits class when it is specialized for \tcode{char} or \tcode{wchar_t}. This class template is described in the header \tcode{}, and is described in Clause~\ref{re.traits}. -\exitnote +\end{note} \rSec1[re.syn]{Header \tcode{} synopsis} @@ -1240,7 +1240,7 @@ return false; } \end{codeblock} -\enterexample +\begin{example} \begin{codeblock} regex_traits t; @@ -1251,8 +1251,8 @@ f |= t.lookup_classname(u.begin(), u.end()); ctype_base::mask m = convert(f); // \tcode{m == ctype_base::digit|ctype_base::upper} \end{codeblock} -\exitexample -\enterexample +\end{example} +\begin{example} \begin{codeblock} regex_traits t; @@ -1263,7 +1263,7 @@ t.isctype('_', f); // returns \tcode{true} t.isctype(' ', f); // returns \tcode{false} \end{codeblock} -\exitexample +\end{example} \end{itemdescr} @@ -1292,9 +1292,9 @@ \begin{itemdescr} \pnum \effects Imbues \tcode{this} with a copy of the -locale \tcode{loc}. \enternote Calling \tcode{imbue} with a +locale \tcode{loc}. \begin{note} Calling \tcode{imbue} with a different locale than the one currently in use invalidates all cached -data held by \tcode{*this}. \exitnote +data held by \tcode{*this}. \end{note} \pnum \returns if no locale has been previously imbued then a copy of the @@ -1354,9 +1354,9 @@ converting the sequence of \tcode{charT} objects to an internal representation. It is not specified what form this representation takes, nor how it is accessed by algorithms that operate on regular -expressions. \enternote Implementations will typically declare +expressions. \begin{note} Implementations will typically declare some function templates as friends of \tcode{basic_regex} to achieve -this \exitnote +this \end{note} \pnum \indexlibrary{\idxcode{regex_error}}% @@ -2593,9 +2593,9 @@ \range{first}{second} which formed that match. Otherwise \tcode{matched} is false, and members \tcode{first} and \tcode{second} point to the end of the sequence -that was searched. \enternote The \tcode{sub_match} objects representing +that was searched. \begin{note} The \tcode{sub_match} objects representing different sub-expressions that did not participate in a regular expression -match need not be distinct.\exitnote +match need not be distinct.\end{note} \begin{codeblock} namespace std { @@ -2787,11 +2787,11 @@ \pnum\returns One plus the number of marked sub-expressions in the regular expression that was matched if \tcode{*this} represents the result of a successful match. Otherwise returns \tcode{0}. -\enternote The state of a \tcode{match_results} object can be modified +\begin{note} The state of a \tcode{match_results} object can be modified only by passing that object to \tcode{regex_match} or \tcode{regex_search}. Sections~\ref{re.alg.match} and~\ref{re.alg.search} specify the effects of those algorithms on their \tcode{match_results} arguments. -\exitnote +\end{note} \end{itemdescr} \indexlibrary{\idxcode{match_results}!\idxcode{max_size}}% @@ -3102,7 +3102,7 @@ \tcode{m1.suffix() == m2.suffix()}. \end{itemize} \end{itemize} -\enternote The algorithm \tcode{equal} is defined in Clause~\ref{algorithms}. \exitnote +\begin{note} The algorithm \tcode{equal} is defined in Clause~\ref{algorithms}. \end{note} \end{itemdescr} \indexlibrary{\idxcode{operator"!=}!\idxcode{match_results}}% @@ -3152,7 +3152,7 @@ that match the entire character sequence are considered. Returns \tcode{true} if such a match exists, \tcode{false} otherwise. -\enterexample +\begin{example} \begin{codeblock} std::regex re("Get|GetValue"); std::cmatch m; @@ -3161,7 +3161,7 @@ regex_search("GetValues", m, re); // returns true, and m[0] contains "Get" regex_match ("GetValues", m, re); // returns false \end{codeblock} -\exitexample +\end{example} \pnum \postconditions @@ -3697,10 +3697,10 @@ \indextext{\idxcode{regex_iterator}!end-of-sequence}% An object of type \tcode{regex_iterator} that is not an end-of-sequence iterator holds a \textit{zero-length match} if \tcode{match[0].matched == true} and -\tcode{match[0].first == match[0].second}. \enternote For +\tcode{match[0].first == match[0].second}. \begin{note} For example, this can occur when the part of the regular expression that matched consists only of an assertion (such as \verb|'^'|, \verb|'$'|, -\tcode{'$\backslash$b'}, \tcode{'$\backslash$B'}). \exitnote +\tcode{'$\backslash$b'}, \tcode{'$\backslash$B'}). \end{note} \rSec3[re.regiter.cnstr]{\tcode{regex_iterator} constructors} @@ -3827,19 +3827,19 @@ shall return \tcode{distance(begin, match[i].\brk{}first)}. \pnum -\enternote This means that \tcode{match.position(i)} gives the +\begin{note} This means that \tcode{match.position(i)} gives the offset from the beginning of the target sequence, which is often not the same as the offset from the sequence passed in the call -to \tcode{regex_search}. \exitnote +to \tcode{regex_search}. \end{note} \pnum It is unspecified how the implementation makes these adjustments. \pnum -\enternote This means that a compiler may call an +\begin{note} This means that a compiler may call an implementation-specific search function, in which case a user-defined specialization of \tcode{regex_search} will not be -called. \exitnote +called. \end{note} \end{itemdescr} \indexlibrary{\idxcode{regex_iterator}!\idxcode{operator++}}% @@ -4006,10 +4006,10 @@ final sequence. \pnum -\enternote For a suffix iterator, data +\begin{note} For a suffix iterator, data member \tcode{suffix.first} is the same as the end of the last match found, and \tcode{suffix\brk.second} is the same as the end of the target -sequence \exitnote +sequence \end{note} \pnum The \textit{current match} is \tcode{(*position).prefix()} if \tcode{subs[N] == -1}, or @@ -4307,9 +4307,9 @@ \indexlibrary{\idxcode{regex_error}}% If the \textit{CV} of a \textit{UnicodeEscapeSequence} is greater than the largest value that can be held in an object of type \tcode{charT} the translator shall -throw an exception object of type \tcode{regex_error}. \enternote +throw an exception object of type \tcode{regex_error}. \begin{note} This means that values of the form \tcode{"uxxxx"} that do not fit in -a character are invalid. \exitnote +a character are invalid. \end{note} \pnum Where the regular expression grammar requires the conversion of a sequence of characters diff --git a/source/special.tex b/source/special.tex index 75e2c6cf99..ed468f52e5 100644 --- a/source/special.tex +++ b/source/special.tex @@ -23,17 +23,17 @@ move constructor and move assignment operator~(\ref{class.copy}), and destructor~(\ref{class.dtor}) are \term{special member functions}. -\enternote The implementation will implicitly declare these member functions for some class +\begin{note} The implementation will implicitly declare these member functions for some class types when the program does not explicitly declare them. The implementation will implicitly define them if they are odr-used~(\ref{basic.def.odr}). -See~\ref{class.ctor}, \ref{class.dtor} and~\ref{class.copy}. \exitnote +See~\ref{class.ctor}, \ref{class.dtor} and~\ref{class.copy}. \end{note} An implicitly-declared special member function is declared at the closing \tcode{\}} of the \grammarterm{class-specifier}. Programs shall not define implicitly-declared special member functions. \pnum Programs may explicitly refer to implicitly-declared special member functions. -\enterexample +\begin{example} a program may explicitly call, take the address of or form a pointer to member to an implicitly-declared special member function. @@ -47,23 +47,23 @@ return *this; } \end{codeblock} -\exitexample +\end{example} \pnum -\enternote +\begin{note} The special member functions affect the way objects of class type are created, copied, moved, and destroyed, and how values can be converted to values of other types. Often such special member functions are called implicitly. -\exitnote +\end{note} \pnum \indextext{access~control!member~function~and}% Special member functions obey the usual access rules (Clause~\ref{class.access}). -\enterexample +\begin{example} declaring a constructor \tcode{protected} ensures that only derived classes and friends can create objects using it. -\exitexample +\end{example} \pnum For a class, its non-static data members, its non-virtual direct base classes, @@ -111,7 +111,7 @@ declaration, each \grammarterm{decl-specifier} in the optional \grammarterm{decl-specifier-seq} shall be \tcode{friend}, \tcode{inline}, \tcode{explicit}, or \tcode{constexpr}. -\enterexample +\begin{example} \begin{codeblock} struct S { @@ -120,7 +120,7 @@ S::S() { } // defines the constructor \end{codeblock} -\exitexample +\end{example} \pnum A constructor is used to initialize objects of its class type. @@ -128,9 +128,9 @@ name lookup; however an explicit type conversion using the functional notation~(\ref{expr.type.conv}) will cause a constructor to be called to initialize an object. -\enternote +\begin{note} For initialization of objects of class type see~\ref{class.init}. -\exitnote +\end{note} \pnum \indextext{\idxcode{const}!constructor~and}% @@ -254,12 +254,12 @@ implicitly defined, all the non-user-provided default constructors for its base classes and its non-static data members shall have been implicitly defined. -\enternote +\begin{note} An implicitly-declared default constructor has an exception specification~(\ref{except.spec}). An explicitly-defaulted definition might have an implicit exception specification, see~\ref{dcl.fct.def}. -\exitnote +\end{note} \pnum \indextext{constructor!implicitly called}% @@ -277,13 +277,13 @@ is implicitly used and the constructor is not accessible (Clause~\ref{class.access}). \pnum -\enternote +\begin{note} \indextext{order~of~execution!base~class constructor}% \indextext{order~of~execution!member constructor}% \ref{class.base.init} describes the order in which constructors for base classes and non-static data members are called and describes how arguments can be specified for the calls to these constructors. -\exitnote +\end{note} \pnum \indextext{restriction!constructor}% @@ -298,33 +298,33 @@ \indextext{constructor!explicit call}% A functional notation type conversion~(\ref{expr.type.conv}) can be used to create new objects of its type. -\enternote +\begin{note} The syntax looks like an explicit call of the constructor. -\exitnote -\enterexample +\end{note} +\begin{example} \indextext{example!constructor}% \begin{codeblock} complex zz = complex(1,2.3); cprint( complex(7.8,1.2) ); \end{codeblock} -\exitexample +\end{example} \pnum An object created in this way is unnamed. -\enternote +\begin{note} \ref{class.temporary} describes the lifetime of temporary objects. -\exitnote -\enternote +\end{note} +\begin{note} Explicit constructor calls do not yield lvalues, see~\ref{basic.lval}. -\exitnote +\end{note} \pnum -\enternote +\begin{note} \indextext{member function!constructor~and}% some language constructs have special semantics when used during construction; see~\ref{class.base.init} and~\ref{class.cdtor}. -\exitnote +\end{note} \pnum During the construction of a @@ -334,7 +334,7 @@ the constructor's \tcode{this} pointer, the value of the object or subobject thus obtained is unspecified. -\enterexample +\begin{example} \begin{codeblock} struct C; @@ -354,7 +354,7 @@ << '\n'; } \end{codeblock} -\exitexample +\end{example} \rSec1[class.temporary]{Temporary objects} @@ -370,24 +370,24 @@ a conversion that creates a prvalue~(\ref{conv.lval}, \ref{expr.static.cast}, \ref{expr.const.cast}, \ref{expr.cast}), throwing an exception~(\ref{except.throw}), and in some initializations~(\ref{dcl.init}). -\enternote +\begin{note} The lifetime of exception objects is described in~\ref{except.throw}. -\exitnote +\end{note} Even when the creation of the temporary object is unevaluated (Clause~\ref{expr}) or otherwise avoided~(\ref{class.copy}), all the semantic restrictions shall be respected as if the temporary object had been created and later destroyed. -\enternote +\begin{note} This includes accessibility~(\ref{class.access}) and whether it is deleted, for the constructor selected and for the destructor. However, in the special case of a function call used as the operand of a \grammarterm{decltype-specifier}~(\ref{expr.call}), no temporary is introduced, so the foregoing does not apply to the prvalue of any such function call. -\exitnote +\end{note} \pnum -\enterexample Consider the following code: +\begin{example} Consider the following code: \begin{codeblock} class X { public: @@ -446,7 +446,7 @@ \tcode{a=f(a)} requires a temporary for the result of \tcode{f(a)}, which is then assigned to \tcode{a}. -\exitexample +\end{example} \pnum \indextext{temporary!constructor~for}% @@ -499,13 +499,13 @@ \item The lifetime of a temporary bound to the returned value in a function return statement~(\ref{stmt.return}) is not extended; the temporary is destroyed at the end of the full-expression in the return statement. -\item A temporary bound to a reference in a \grammarterm{new-initializer}~(\ref{expr.new}) persists until the completion of the full-expression containing the \grammarterm{new-initializer}. \enterexample +\item A temporary bound to a reference in a \grammarterm{new-initializer}~(\ref{expr.new}) persists until the completion of the full-expression containing the \grammarterm{new-initializer}. \begin{example} \begin{codeblock} struct S { int mi; const std::pair& mp; }; S a { 1, {2,3} }; S* p = new S{ 1, {2,3} }; // Creates dangling reference \end{codeblock} -\exitexample \enternote This may introduce a dangling reference, and implementations are encouraged to issue a warning in such a case. \exitnote +\end{example} \begin{note} This may introduce a dangling reference, and implementations are encouraged to issue a warning in such a case. \end{note} \end{itemize} The destruction of a temporary whose lifetime is not extended by being @@ -532,7 +532,7 @@ the temporary shall be destroyed after \tcode{obj2} is destroyed. -\enterexample +\begin{example} \begin{codeblock} struct S { @@ -611,7 +611,7 @@ \tcode{T3} shall be destroyed before \tcode{obj1}. -\exitexample +\end{example} \rSec1[class.conv]{Conversions} @@ -635,17 +635,17 @@ Access control is applied after ambiguity resolution~(\ref{basic.lookup}). \pnum -\enternote +\begin{note} See~\ref{over.match} for a discussion of the use of conversions in function calls as well as examples below. -\exitnote +\end{note} \pnum \indextext{conversion!implicit user-defined}% At most one user-defined conversion (constructor or conversion function) is implicitly applied to a single value. -\enterexample +\begin{example} \begin{codeblock} struct X { @@ -661,7 +661,7 @@ // \tcode{a.operator X().operator int()} not tried int c = X(a); // OK: \tcode{a.operator X().operator int()} \end{codeblock} -\exitexample +\end{example} \pnum User-defined conversions are used implicitly only if they are unambiguous. @@ -670,7 +670,7 @@ in a base class unless the two functions convert to the same type. Function overload resolution~(\ref{over.match.best}) selects the best conversion function to perform the conversion. -\enterexample +\begin{example} \begin{codeblock} struct X { @@ -687,7 +687,7 @@ } } \end{codeblock} -\exitexample +\end{example} \rSec2[class.conv.ctor]{Conversion by constructor}% \indextext{conversion!user-defined} @@ -702,7 +702,7 @@ Such a constructor is called a \indexdefn{constructor!converting}% \term{converting constructor}. -\enterexample +\begin{example} \indextext{Jessie}% \begin{codeblock} @@ -720,17 +720,17 @@ f({1, 2}); // \tcode{f(X(1,2))} } \end{codeblock} -\exitexample +\end{example} \pnum -\enternote +\begin{note} An explicit constructor constructs objects just like non-explicit constructors, but does so only where the direct-initialization syntax~(\ref{dcl.init}) or where casts~(\ref{expr.static.cast}, \ref{expr.cast}) are explicitly used; see also~\ref{over.match.copy}. A default constructor may be an explicit constructor; such a constructor will be used to perform default-initialization or value-initialization~(\ref{dcl.init}). -\enterexample +\begin{example} \begin{codeblock} struct Z { @@ -748,17 +748,17 @@ Z a5 = static_cast(1); // OK: explicit cast used Z a6 = { 3, 4 }; // error: no implicit conversion \end{codeblock} -\exitexample -\exitnote +\end{example} +\end{note} \pnum A non-explicit copy/move constructor~(\ref{class.copy}) is a converting constructor. -\enternote +\begin{note} An implicitly-declared copy/move constructor is not an explicit constructor; it may be called for implicit type conversions. -\exitnote +\end{note} \rSec2[class.conv.fct]{Conversion functions}% \indextext{function!conversion}% @@ -805,7 +805,7 @@ such conversion functions can be declared and can potentially be reached through a call to a virtual conversion function in a base class.} -\enterexample +\begin{example} \begin{codeblock} struct X { @@ -821,11 +821,11 @@ In all three cases the value assigned will be converted by \tcode{X::operator int()}. -\exitexample +\end{example} \pnum A conversion function may be explicit~(\ref{dcl.fct.spec}), in which case it is only considered as a user-defined conversion for direct-initialization~(\ref{dcl.init}). Otherwise, user-defined conversions are not restricted to use in assignments and initializations. -\enterexample +\begin{example} \begin{codeblock} class Y { }; @@ -846,7 +846,7 @@ } } \end{codeblock} -\exitexample +\end{example} \pnum The @@ -858,10 +858,10 @@ \grammarterm{conversion-function-id} is the longest sequence of tokens that could possibly form a \grammarterm{conversion-type-id}. -\enternote +\begin{note} This prevents ambiguities between the declarator operator \tcode{*} and its expression counterparts. -\enterexample +\begin{example} \begin{codeblock} &ac.operator int*i; // syntax error: @@ -870,15 +870,15 @@ \end{codeblock} The \tcode{*} is the pointer declarator and not the multiplication operator. -\exitexample +\end{example} This rule also prevents ambiguities for attributes. -\enterexample +\begin{example} \begin{codeblock} operator int [[noreturn]] (); // error: \tcode{noreturn} attribute applied to a type \end{codeblock} -\exitexample -\exitnote +\end{example} +\end{note} \pnum \indextext{conversion!inheritance~of user-defined}% @@ -1064,11 +1064,11 @@ (whether user- or implicitly-declared) is virtual. \pnum -\enternote +\begin{note} \indextext{member function!destructor~and}% some language constructs have special semantics when used during destruction; see~\ref{class.cdtor}. -\exitnote +\end{note} \pnum \indextext{destructor!implicit call}% @@ -1093,8 +1093,8 @@ \grammarterm{delete-expression}~(\ref{expr.delete}) for a constructed object allocated by a \grammarterm{new-expression}~(\ref{expr.new}); the context of the invocation is the \grammarterm{delete-expression}. -\enternote An array of class type contains several subobjects for each of which -the destructor is invoked. \exitnote +\begin{note} An array of class type contains several subobjects for each of which +the destructor is invoked. \end{note} A destructor can also be invoked explicitly. A destructor is \term{potentially invoked} if it is invoked or as specified in~\ref{expr.new}, \ref{class.base.init}, and~\ref{except.throw}. @@ -1108,11 +1108,11 @@ non-virtual destructor of the destructor's class (see~\ref{expr.delete}). If the lookup fails or if the deallocation function has a deleted definition~(\ref{dcl.fct.def}), the program is ill-formed. -\enternote +\begin{note} This assures that a deallocation function corresponding to the dynamic type of an object is available for the \grammarterm{delete-expression}~(\ref{class.free}). -\exitnote +\end{note} \pnum \indextext{destructor!explicit call}% @@ -1127,9 +1127,9 @@ not of a class derived from the destructor's class type (including when the destructor is invoked via a null pointer value), the program has undefined behavior. -\enternote invoking \tcode{delete} on a null pointer does not call the -destructor; see \ref{expr.delete}. \exitnote -\enterexample +\begin{note} invoking \tcode{delete} on a null pointer does not call the +destructor; see \ref{expr.delete}. \end{note} +\begin{example} \begin{codeblock} struct B { @@ -1151,18 +1151,18 @@ B_ptr->B_alias::~B_alias(); // calls \tcode{B}'s destructor } \end{codeblock} -\exitexample -\enternote +\end{example} +\begin{note} An explicit destructor call must always be written using a member access operator~(\ref{expr.ref}) or a qualified-id~(\ref{expr.prim}); in particular, the \grammarterm{unary-expression} \tcode{\~{}X()} in a member function is not an explicit destructor call~(\ref{expr.unary.op}). -\exitnote +\end{note} \pnum -\enternote +\begin{note} \indextext{object!destructor~and placement~of}% explicit calls of destructors are rarely needed. One use of such calls is for objects placed at specific @@ -1189,20 +1189,20 @@ p->X::~X(); // cleanup } \end{codeblock} -\exitnote +\end{note} \pnum Once a destructor is invoked for an object, the object no longer exists; the behavior is undefined if the destructor is invoked for an object whose lifetime has ended~(\ref{basic.life}). -\enterexample +\begin{example} if the destructor for an automatic object is explicitly invoked, and the block is subsequently left in a manner that would ordinarily invoke implicit destruction of the object, the behavior is undefined. -\exitexample +\end{example} \pnum -\enternote +\begin{note} \indextext{fundamental~type!destructor~and}% the notation for explicit call of a destructor can be used for any scalar type name~(\ref{expr.pseudo}). @@ -1215,7 +1215,7 @@ I* p; p->I::~I(); \end{codeblock} -\exitnote +\end{note} \rSec1[class.free]{Free store}% \indextext{free store}% @@ -1228,7 +1228,7 @@ \tcode{static}). \pnum -\enterexample +\begin{example} \begin{codeblock} class Arena; @@ -1245,7 +1245,7 @@ new D1; // ill-formed: \tcode{::operator new(std::size_t)} hidden } \end{codeblock} -\exitexample +\end{example} \pnum \indextext{\idxcode{delete}}% @@ -1292,7 +1292,7 @@ is a static member (even if not explicitly declared \tcode{static}). \indextext{example!\idxcode{delete}}% -\enterexample +\begin{example} \begin{codeblock} class X { @@ -1305,13 +1305,13 @@ void operator delete[](void*); }; \end{codeblock} -\exitexample +\end{example} \pnum Since member allocation and deallocation functions are \tcode{static} they cannot be virtual. -\enternote +\begin{note} \indextext{example!destructor~and \tcode{delete}}% \indextext{example!scope~of \tcode{delete}}% however, when the @@ -1345,8 +1345,8 @@ is deallocated by \tcode{D::operator delete()}, due to the virtual destructor. -\exitnote -\enternote +\end{note} +\begin{note} Virtual destructors have no effect on the deallocation function actually called when the \grammarterm{cast-expression} @@ -1372,26 +1372,26 @@ delete[] bp; // undefined behavior } \end{codeblock} -\exitnote +\end{note} \pnum Access to the deallocation function is checked statically. Hence, even though a different one might actually be executed, the statically visible deallocation function is required to be accessible. -\enterexample +\begin{example} for the call on line //1 above, if \tcode{B::operator delete()} had been \tcode{private}, the delete expression would have been ill-formed. -\exitexample +\end{example} \pnum -\enternote +\begin{note} If a deallocation function has no explicit \grammarterm{exception-specification}, it has a non-throwing exception specification~(\ref{except.spec}). -\exitnote +\end{note} \rSec1[class.init]{Initialization}% \indextext{initialization!class~object|(}% @@ -1415,10 +1415,10 @@ (either explicitly or implicitly) and the elements are initialized by constructor, the constructor shall be called for each element of the array, following the subscript order; see~\ref{dcl.array}. -\enternote +\begin{note} Destructors for the array elements are called in reverse order of their construction. -\exitnote +\end{note} \rSec2[class.expl.init]{Explicit initialization}% \indextext{initialization!explicit}% @@ -1441,7 +1441,7 @@ Either direct-initialization semantics or copy-initialization semantics apply; see~\ref{dcl.init}. \indextext{example!constructor~and initialization}% -\enterexample +\begin{example} \begin{codeblock} struct complex { @@ -1468,19 +1468,19 @@ complex g = { 1, 2 }; // initialize by a call of // \tcode{complex(double, double)} \end{codeblock} -\exitexample -\enternote +\end{example} +\begin{note} \indextext{initialization!overloaded assignment~and}% overloading of the assignment operator~(\ref{over.ass}) has no effect on initialization. -\exitnote +\end{note} \pnum \indextext{initialization!array~of class~objects}% \indextext{constructor!array~of class~objects~and}% An object of class type can also be initialized by a \grammarterm{braced-init-list}. List-initialization semantics apply; -see~\ref{dcl.init} and~\ref{dcl.init.list}. \enterexample +see~\ref{dcl.init} and~\ref{dcl.init.list}. \begin{example} \begin{codeblock} complex v[6] = { 1, complex(1,2), complex(), 2 }; @@ -1519,16 +1519,16 @@ \tcode{complex::complex(double)} is called for the initialization of \tcode{x.c}. -\exitexample -\enternote +\end{example} +\begin{note} Braces can be elided in the \grammarterm{initializer-list} for any aggregate, even if the aggregate has members of a class type with user-defined type conversions; see~\ref{dcl.init.aggr}. -\exitnote +\end{note} \pnum -\enternote +\begin{note} If \tcode{T} is a class type with no default constructor, @@ -1537,14 +1537,14 @@ (or array thereof) is ill-formed if no \grammarterm{initializer} is explicitly specified (see~\ref{class.init} and~\ref{dcl.init}). -\exitnote +\end{note} \pnum -\enternote +\begin{note} \indextext{order~of~execution!constructor~and \tcode{static}~objects}% the order in which objects with static or thread storage duration are initialized is described in~\ref{basic.start.dynamic} and~\ref{stmt.dcl}. -\exitnote +\end{note} \rSec2[class.base.init]{Initializing bases and members}% \indextext{initialization!base~class}% @@ -1585,7 +1585,7 @@ \grammarterm{identifier} is looked up in the scope of the constructor's class and, if not found in that scope, it is looked up in the scope containing the constructor's definition. -\enternote +\begin{note} If the constructor's class contains a member with the same name as a direct or virtual base class of the class, a \grammarterm{mem-initializer-id} @@ -1594,7 +1594,7 @@ A \grammarterm{mem-initializer-id} for the hidden base class may be specified using a qualified name. -\exitnote +\end{note} Unless the \grammarterm{mem-initializer-id} names the constructor's class, @@ -1608,7 +1608,7 @@ A \grammarterm{mem-initializer-list} can initialize a base class using any \grammarterm{class-or-decltype} that denotes that base class type. -\enterexample +\begin{example} \begin{codeblock} struct A { A(); }; @@ -1617,7 +1617,7 @@ struct C: public A, public B { C(); }; C::C(): global_A() { } // mem-initializer for base \tcode{A} \end{codeblock} -\exitexample +\end{example} \pnum If a @@ -1626,7 +1626,7 @@ an inherited virtual base class, the \grammarterm{mem-initializer} is ill-formed. -\enterexample +\begin{example} \begin{codeblock} struct A { A(); }; @@ -1634,7 +1634,7 @@ struct C: public A, public B { C(); }; C::C(): A() { } // ill-formed: which \tcode{A}? \end{codeblock} -\exitexample +\end{example} \pnum A @@ -1663,7 +1663,7 @@ object's construction). The target constructor is selected by overload resolution. Once the target constructor returns, the body of the delegating constructor is executed. If a constructor delegates to itself directly or indirectly, -the program is ill-formed; no diagnostic is required. \enterexample +the program is ill-formed; no diagnostic is required. \begin{example} \begin{codeblock} struct C { @@ -1673,7 +1673,7 @@ C( double d ) : C('a') { } // \#4: ill-formed due to recursion with \#3 }; \end{codeblock} -\exitexample +\end{example} \pnum \indextext{initialization!base~class}% @@ -1687,7 +1687,7 @@ designated subobject (or, in the case of a delegating constructor, the complete class object) according to the initialization rules of~\ref{dcl.init} for direct-initialization. -\enterexample +\begin{example} \begin{codeblock} struct B1 { B1(int); /* ... */ }; @@ -1702,7 +1702,7 @@ { /* ... */ } D d(10); \end{codeblock} -\exitexample +\end{example} The initialization performed by each \grammarterm{mem-initializer} constitutes a full-expression. @@ -1717,14 +1717,14 @@ \pnum A temporary expression bound to a reference member in a \grammarterm{mem-initializer} is ill-formed. -\enterexample +\begin{example} \begin{codeblock} struct A { A() : v(42) { } // error const int& v; }; \end{codeblock} -\exitexample +\end{example} \pnum In a non-delegating constructor, if @@ -1757,14 +1757,14 @@ \item otherwise, the entity is default-initialized~(\ref{dcl.init}). \end{itemize} -\enternote An abstract class~(\ref{class.abstract}) is never a most derived +\begin{note} An abstract class~(\ref{class.abstract}) is never a most derived class, thus its constructors never initialize virtual base classes, therefore the -corresponding \grammarterm{mem-initializer}{s} may be omitted. \exitnote +corresponding \grammarterm{mem-initializer}{s} may be omitted. \end{note} An attempt to initialize more than one non-static data member of a union renders the program ill-formed. \indextext{initialization!const member}% \indextext{initialization!reference member}% -\enternote +\begin{note} After the call to a constructor for class \tcode{X} for an object with automatic or dynamic storage duration @@ -1776,8 +1776,8 @@ given a value during execution of the \grammarterm{compound-statement} of the body of the constructor, the member has an indeterminate value. -\exitnote -\enterexample +\end{note} +\begin{example} \begin{codeblock} struct A { A(); @@ -1795,14 +1795,14 @@ int j = 5; // OK: \tcode{j} has the value \tcode{5} }; \end{codeblock} -\exitexample +\end{example} \pnum If a given non-static data member has both a default member initializer and a \grammarterm{mem-initializer}, the initialization specified by the \grammarterm{mem-initializer} is performed, and the non-static data member's default member initializer is ignored. -\enterexample Given +\begin{example} Given \begin{codeblock} struct A { int i = /* some integer expression with side effects */ ; @@ -1816,12 +1816,12 @@ \indextext{side effects}% side effects in \tcode{i}'s default member initializer will not take place. -\exitexample +\end{example} \pnum A temporary expression bound to a reference member from a default member initializer is ill-formed. -\enterexample +\begin{example} \begin{codeblock} struct A { A() = default; // OK @@ -1831,13 +1831,13 @@ A a1; // error: ill-formed binding of temporary to reference A a2(1); // OK, unfortunately \end{codeblock} -\exitexample +\end{example} \pnum In a non-delegating constructor, the destructor for each potentially constructed subobject of class type is potentially invoked~(\ref{class.dtor}). -\enternote This provision ensures that destructors can be called for fully-constructed -sub-objects in case an exception is thrown~(\ref{except.ctor}). \exitnote +\begin{note} This provision ensures that destructors can be called for fully-constructed +sub-objects in case an exception is thrown~(\ref{except.ctor}). \end{note} \pnum In a non-delegating constructor, initialization @@ -1871,13 +1871,13 @@ body is executed. \end{itemize} -\enternote +\begin{note} The declaration order is mandated to ensure that base and member subobjects are destroyed in the reverse order of initialization. -\exitnote +\end{note} \pnum -\enterexample +\begin{example} \begin{codeblock} struct V { V(); @@ -1908,7 +1908,7 @@ B b(3); // use \tcode{V()} C c(4); // use \tcode{V()} \end{codeblock} -\exitexample +\end{example} \pnum \indextext{initializer!scope~of member}% @@ -1920,7 +1920,7 @@ are evaluated in the scope of the constructor for which the \grammarterm{mem-initializer} is specified. -\enterexample +\begin{example} \begin{codeblock} class X { @@ -1953,8 +1953,8 @@ this takes place each time an object of class \tcode{X} is created. -\exitexample -\enternote +\end{example} +\begin{note} Because the \grammarterm{mem-initializer} are evaluated in the scope of the constructor, the @@ -1964,7 +1964,7 @@ of a \grammarterm{mem-initializer} to refer to the object being initialized. -\exitnote +\end{note} \pnum \indextext{initialization!member function call during}% @@ -1981,7 +1981,7 @@ before all the \grammarterm{mem-initializer}{s} for base classes have completed, the result of the operation is undefined. -\enterexample +\begin{example} \begin{codeblock} class A { @@ -2011,10 +2011,10 @@ i(f()) { } // well-defined: bases are all initialized }; \end{codeblock} -\exitexample +\end{example} \pnum -\enternote +\begin{note} \ref{class.cdtor} describes the result of virtual function calls, \tcode{typeid} and @@ -2023,14 +2023,14 @@ that is, describes the \term{polymorphic behavior} of an object under construction. -\exitnote +\end{note} \pnum \indextext{initializer!pack expansion}% A \grammarterm{mem-initializer} followed by an ellipsis is a pack expansion~(\ref{temp.variadic}) that initializes the base classes specified by a pack expansion in the \grammarterm{base-specifier-list} -for the class. \enterexample +for the class. \begin{example} \begin{codeblock} template @@ -2040,7 +2040,7 @@ }; \end{codeblock} -\exitexample% +\end{example}% \indextext{initialization!class~object|)} \rSec2[class.inhctor.init]{Initialization by inherited constructor}% @@ -2058,7 +2058,7 @@ The complete initialization is considered to be a single function call; in particular, the initialization of the inherited constructor's parameters is sequenced before the initialization of any part of the \tcode{D} object. -\enterexample +\begin{example} \begin{codeblock} struct B1 { B1(int, ...) { } @@ -2104,12 +2104,12 @@ Class template \tcode{Log} wraps any class and forwards all of its constructors, while writing a message to the standard log whenever an object of class \tcode{Log} is destroyed. -\exitexample +\end{example} \pnum If the constructor was inherited from multiple base class subobjects of type \tcode{B}, the program is ill-formed. -\enterexample +\begin{example} \begin{codeblock} struct A { A(int); }; struct B : A { using A::A; }; @@ -2141,7 +2141,7 @@ P p(0); // OK: use \tcode{M(0)} to initialize \tcode{N}{'s} base class, // use \tcode{M()} to initialize \tcode{O}{'s} base class \end{codeblock} -\exitexample +\end{example} \pnum When an object is initialized by an inheriting constructor, @@ -2161,7 +2161,7 @@ undefined behavior. For an object with a non-trivial destructor, referring to any non-static member or base class of the object after the destructor finishes execution results in undefined behavior. -\enterexample +\begin{example} \begin{codeblock} struct X { int i; }; @@ -2195,7 +2195,7 @@ } }; \end{codeblock} -\exitexample +\end{example} \pnum \indextext{construction!pointer to member or base}% @@ -2222,7 +2222,7 @@ shall have started and its destruction shall not have completed, otherwise the computation of the pointer value (or accessing the member value) results in undefined behavior. -\enterexample +\begin{example} \begin{codeblock} struct A { }; @@ -2244,7 +2244,7 @@ } }; \end{codeblock} -\exitexample +\end{example} \pnum \indextext{virtual~function~call!constructor~and}% @@ -2267,7 +2267,7 @@ the complete object of \tcode{x} or one of that object's base class subobjects but not \tcode{x} or one of its base class subobjects, the behavior is undefined. -\enterexample +\begin{example} \begin{codeblock} struct V { @@ -2297,7 +2297,7 @@ a->f(); // undefined behavior, \tcode{a}'s type not a base of \tcode{B} } \end{codeblock} -\exitexample +\end{example} \pnum \indextext{construction!\idxcode{typeid} operator}% @@ -2353,7 +2353,7 @@ \tcode{dynamic_cast} results in undefined behavior. -\enterexample +\begin{example} \begin{codeblock} struct V { @@ -2381,7 +2381,7 @@ // \tcode{a} has type \tcode{A*}, \tcode{A} not a base of \tcode{B} } \end{codeblock} -\exitexample% +\end{example}% \indextext{destruction|)}% \indextext{construction|)} @@ -2417,7 +2417,7 @@ \tcode{const volatile X\&}, and either there are no other parameters or else all other parameters have default arguments~(\ref{dcl.fct.default}). -\enterexample +\begin{example} \tcode{X::X(const X\&)} and \tcode{X::X(X\&,int=1)} @@ -2432,7 +2432,7 @@ X b(a, 0); // calls \tcode{X(const X\&, int);} X c = b; // calls \tcode{X(const X\&, int);} \end{codeblock} -\exitexample +\end{example} \pnum A non-template constructor for class \tcode{X} is a move constructor if its @@ -2440,7 +2440,7 @@ \tcode{volatile X\&\&}, or \tcode{const volatile X\&\&}, and either there are no other parameters or else all other parameters have default arguments~(\ref{dcl.fct.default}). -\enterexample \tcode{Y::Y(Y\&\&)} is a move constructor. +\begin{example} \tcode{Y::Y(Y\&\&)} is a move constructor. \begin{codeblock} struct Y { Y(const Y&); @@ -2450,12 +2450,12 @@ Y d(f(1)); // calls \tcode{Y(Y\&\&)} Y e = d; // calls \tcode{Y(const Y\&)} \end{codeblock} -\exitexample +\end{example} \pnum -\enternote +\begin{note} All forms of copy/move constructor may be declared for a class. -\enterexample +\begin{example} \begin{codeblock} struct X { @@ -2465,11 +2465,11 @@ X(const X&&); // OK, but possibly not sensible }; \end{codeblock} -\exitexample -\exitnote +\end{example} +\end{note} \pnum -\enternote +\begin{note} If a class \tcode{X} only has a copy constructor with a parameter of type @@ -2484,7 +2484,7 @@ (possibly cv-qualified) \tcode{X}. -\enterexample +\begin{example} \begin{codeblock} struct X { @@ -2494,8 +2494,8 @@ const X cx; X x = cx; // error: \tcode{X::X(X\&)} cannot copy \tcode{cx} into \tcode{x} \end{codeblock} -\exitexample -\exitnote +\end{example} +\end{note} \pnum A declaration of a constructor for a class @@ -2506,7 +2506,7 @@ default arguments. A member function template is never instantiated to produce such a constructor signature. -\enterexample +\begin{example} \begin{codeblock} struct S { template S(T); @@ -2520,7 +2520,7 @@ // uses the implicitly declared copy constructor } \end{codeblock} -\exitexample +\end{example} \pnum \indextext{constructor!copy!implicitly declared}% @@ -2582,9 +2582,9 @@ \tcode{X} does not have a user-declared destructor. \end{itemize} -\enternote When the move constructor is not implicitly declared or explicitly supplied, +\begin{note} When the move constructor is not implicitly declared or explicitly supplied, expressions that otherwise would have invoked the move constructor may instead invoke -a copy constructor. \exitnote +a copy constructor. \end{note} \pnum The implicitly-declared move constructor for class \tcode{X} will have the form @@ -2620,10 +2620,10 @@ A defaulted move constructor that is defined as deleted is ignored by overload resolution~(\ref{over.match}, \ref{over.over}). -\enternote +\begin{note} A deleted move constructor would otherwise interfere with initialization from an rvalue which can use the copy constructor instead. -\exitnote +\end{note} \pnum \indextext{constructor!copy!trivial}% @@ -2666,10 +2666,10 @@ \term{implicitly defined} if it is odr-used~(\ref{basic.def.odr}) or when it is explicitly defaulted after its first declaration. -\enternote +\begin{note} The copy/move constructor is implicitly defined even if the implementation elided its odr-use (\ref{basic.def.odr}, \ref{class.temporary}). -\exitnote +\end{note} If the implicitly-defined constructor would satisfy the requirements of a \tcode{constexpr} constructor~(\ref{dcl.constexpr}), the implicitly-defined constructor is \tcode{constexpr}. @@ -2680,16 +2680,16 @@ all non-user-provided copy/move constructors for its potentially constructed subobjects shall have been implicitly defined. -\enternote +\begin{note} An implicitly-declared copy/move constructor has an implied exception specification~(\ref{except.spec}). -\exitnote +\end{note} \pnum The implicitly-defined copy/move constructor for a non-union class \tcode{X} performs a memberwise copy/move of its bases and members. -\enternote Default member initializers of non-static data members are ignored. See also the example in~\ref{class.base.init}. \exitnote +\begin{note} Default member initializers of non-static data members are ignored. See also the example in~\ref{class.base.init}. \end{note} The order of initialization is the same as the order of initialization of bases and members in a user-defined constructor (see~\ref{class.base.init}). Let \tcode{x} be either the parameter of the constructor or, for the move constructor, an @@ -2733,14 +2733,14 @@ implicit declaration of a copy assignment operator. Such assignment operators participate in overload resolution with other assignment operators, including copy assignment operators, and, if selected, will be used to assign an object.} -\enternote +\begin{note} An overloaded assignment operator must be declared to have only one parameter; see~\ref{over.ass}. -\exitnote -\enternote +\end{note} +\begin{note} More than one form of copy assignment operator may be declared for a class. -\exitnote -\enternote +\end{note} +\begin{note} If a class \tcode{X} only has a copy assignment operator with a parameter of type @@ -2749,7 +2749,7 @@ \tcode{X} cannot be assigned to an object of type \tcode{X}. -\enterexample +\begin{example} \begin{codeblock} struct X { @@ -2762,8 +2762,8 @@ x = cx; // error: \tcode{X::operator=(X\&)} cannot assign \tcode{cx} into \tcode{x} } \end{codeblock} -\exitexample -\exitnote +\end{example} +\end{note} \pnum \indextext{assignment operator!copy!implicitly declared}% @@ -2830,10 +2830,10 @@ A user-declared move assignment operator \tcode{X::operator=} is a non-static non-template member function of class \tcode{X} with exactly one parameter of type \tcode{X\&\&}, \tcode{const X\&\&}, \tcode{volatile X\&\&}, or -\tcode{const volatile X\&\&}. \enternote An overloaded assignment operator must be -declared to have only one parameter; see~\ref{over.ass}. \exitnote{} -\enternote More -than one form of move assignment operator may be declared for a class. \exitnote +\tcode{const volatile X\&\&}. \begin{note} An overloaded assignment operator must be +declared to have only one parameter; see~\ref{over.ass}. \end{note}{} +\begin{note} More +than one form of move assignment operator may be declared for a class. \end{note} \pnum \indextext{assignment operator!move!implicitly declared}% @@ -2855,7 +2855,7 @@ \tcode{X} does not have a user-declared destructor. \end{itemize} -\enterexample The class definition +\begin{example} The class definition \begin{codeblock} struct S { int a; @@ -2874,7 +2874,7 @@ S& operator=(S&&) = default; }; \end{codeblock} -\exitexample +\end{example} \pnum The implicitly-declared move assignment operator for a class \tcode{X} will have the form @@ -3002,10 +3002,10 @@ all non-user-provided copy/move assignment operators for its direct base classes and its non-static data members shall have been implicitly defined. -\enternote +\begin{note} An implicitly-declared copy/move assignment operator has an implied exception specification~(\ref{except.spec}). -\exitnote +\end{note} \pnum The implicitly-defined copy/move assignment operator for a @@ -3037,7 +3037,7 @@ It is unspecified whether subobjects representing virtual base classes are assigned more than once by the implicitly-defined copy/move assignment operator. -\enterexample +\begin{example} \begin{codeblock} struct V { }; @@ -3050,7 +3050,7 @@ \tcode{V} is assigned twice by the implicitly-defined copy/move assignment operator for \tcode{C}. -\exitexample +\end{example} \pnum The implicitly-defined copy assignment operator for a @@ -3066,11 +3066,11 @@ A program is ill-formed if the copy/move constructor or the copy/move assignment operator for an object is implicitly odr-used and the special member function is not accessible (Clause~\ref{class.access}). -\enternote +\begin{note} Copying/moving one object into another using the copy/move constructor or the copy/move assignment operator does not change the layout or size of either object. -\exitnote +\end{note} \pnum \indextext{temporary!elimination~of}% @@ -3134,11 +3134,11 @@ object if the meaning of the program will be unchanged except for the execution of constructors and destructors for the object declared by the \nonterminal{exception-declaration}. -\enternote There cannot be a move from the exception object because it is -always an lvalue. \exitnote +\begin{note} There cannot be a move from the exception object because it is +always an lvalue. \end{note} \end{itemize} -\enterexample +\begin{example} \begin{codeblock} class Thing { @@ -3175,7 +3175,7 @@ exit. Adding a move constructor to \tcode{Thing} has the same effect, but it is the move construction from the temporary object to \tcode{t2} that is elided. -\exitexample +\end{example} \pnum When the criteria for elision of a copy/move operation are met, @@ -3193,12 +3193,12 @@ or if the type of the first parameter of the selected constructor is not an rvalue reference to the object's type (possibly cv-qualified), overload resolution is performed again, considering the object as an lvalue. -\enternote This two-stage overload resolution must be performed regardless +\begin{note} This two-stage overload resolution must be performed regardless of whether copy elision will occur. It determines the constructor to be called if elision is not performed, and the selected constructor must be accessible even if -the call is elided. \exitnote +the call is elided. \end{note} -\enterexample +\begin{example} \begin{codeblock} class Thing { public: @@ -3218,4 +3218,4 @@ Thing t2 = f(false); // OK: \tcode{Thing(Thing\&\&)} used (or elided) to construct t2 \end{codeblock} -\exitexample +\end{example} diff --git a/source/statements.tex b/source/statements.tex index de99fc179f..4fcfb4180c 100644 --- a/source/statements.tex +++ b/source/statements.tex @@ -51,11 +51,11 @@ \indextext{name~space!label}% Labels have their own name space and do not interfere with other identifiers. -\enternote +\begin{note} A label may have the same name as another declaration in the same scope or a \grammarterm{template-parameter} from an enclosing scope. Unqualified name lookup~(\ref{basic.lookup.unqual}) ignores labels. -\exitnote +\end{note} \pnum \indextext{label!\idxcode{case}}% @@ -84,13 +84,13 @@ \indextext{statement!empty}% An expression statement with the expression missing is called a \defn{null statement}. -\enternote +\begin{note} Most statements are expression statements --- usually assignments or function calls. A null statement is useful to carry a label just before the \tcode{\}} of a compound statement and to supply a null body to an iteration statement such as a \tcode{while} statement~(\ref{stmt.while}). -\exitnote +\end{note} \rSec1[stmt.block]{Compound statement or block}% \indextext{statement!compound}% @@ -113,9 +113,9 @@ \end{bnf} A compound statement defines a block scope~(\ref{basic.scope}). -\enternote +\begin{note} A declaration is a \grammarterm{}{statement}~(\ref{stmt.dcl}). -\exitnote +\end{note} \rSec1[stmt.select]{Selection statements}% \indextext{statement!selection|(} @@ -151,7 +151,7 @@ selection-statement is a single statement and not a \grammarterm{compound-statement,} it is as if it was rewritten to be a compound-statement containing the original substatement. -\enterexample +\begin{example} \begin{codeblock} if (x) @@ -167,7 +167,7 @@ \end{codeblock} Thus after the \tcode{if} statement, \tcode{i} is no longer in scope. -\exitexample +\end{example} \pnum \indextext{\idxgram{condition}{s}!rules~for}% @@ -189,7 +189,7 @@ condition. If the name is re-declared in the outermost block of a substatement controlled by the condition, the declaration that re-declares the name is ill-formed. -\enterexample +\begin{example} \begin{codeblock} if (int x = f()) { @@ -199,7 +199,7 @@ int x; // ill-formed, redeclaration of \tcode{x} } \end{codeblock} -\exitexample +\end{example} \pnum The value of a \grammarterm{}{condition} that is an initialized declaration @@ -304,7 +304,7 @@ \tcode{case} and \tcode{default} labels in themselves do not alter the flow of control, which continues unimpeded across such labels. To exit from a switch, see \tcode{break},~\ref{stmt.break}. -\enternote +\begin{note} Usually, the substatement that is the subject of a switch is compound and \tcode{case} and \tcode{default} labels appear on the top-level statements contained within the (compound) substatement, but this is not @@ -312,7 +312,7 @@ \indextext{statement!declaration~in \tcode{switch}}% Declarations can appear in the substatement of a \grammarterm{switch-statement}. -\exitnote% +\end{note}% \indextext{statement!selection|)} \rSec1[stmt.iter]{Iteration statements}% @@ -351,9 +351,9 @@ See~\ref{dcl.meaning} for the optional \grammarterm{attribute-specifier-seq} in a \grammarterm{for-range-declaration}. -\enternote +\begin{note} A \grammarterm{for-init-statement} ends with a semicolon. -\exitnote +\end{note} \pnum The substatement in an \grammarterm{iteration-statement} implicitly defines @@ -364,7 +364,7 @@ If the substatement in an iteration-statement is a single statement and not a \grammarterm{compound-statement,} it is as if it was rewritten to be a compound-statement containing the original statement. -\enterexample +\begin{example} \begin{codeblock} while (--x >= 0) @@ -381,13 +381,13 @@ \pnum Thus after the \tcode{while} statement, \tcode{i} is no longer in scope. -\exitexample +\end{example} \pnum -\enternote +\begin{note} The requirements on \grammarterm{}{condition}{s} in iteration statements are described in~\ref{stmt.select}. -\exitnote +\end{note} \rSec2[stmt.while]{The \tcode{while} statement}% \indextext{statement!\idxcode{while}} @@ -424,7 +424,7 @@ The variable created in a condition is destroyed and created with each iteration of the loop. -\enterexample +\begin{example} \begin{codeblock} struct A { @@ -443,7 +443,7 @@ In the while-loop, the constructor and destructor are each called twice, once for the condition that succeeds and once for the condition that fails. -\exitexample +\end{example} \rSec2[stmt.do]{The \tcode{do} statement}% \indextext{statement!\idxcode{do}} @@ -486,13 +486,13 @@ \tcode{continue} in \grammarterm{statement} (not enclosed in another iteration statement) will execute \grammarterm{expression} before re-evaluating \grammarterm{condition}. -\enternote +\begin{note} Thus the first statement specifies initialization for the loop; the condition~(\ref{stmt.select}) specifies a test, sequenced before each iteration, such that the loop is exited when the condition becomes \tcode{false}; the expression often specifies incrementing that is sequenced after each iteration. -\exitnote +\end{note} \pnum Either or both of the \grammarterm{condition} @@ -506,7 +506,7 @@ \indextext{\idxcode{for}!scope~of declaration~in}% If the \grammarterm{for-init-statement} is a declaration, the scope of the name(s) declared extends to the end of the \tcode{for} statement. -\enterexample +\begin{example} \begin{codeblock} int i = 42; @@ -517,7 +517,7 @@ int j = i; // \tcode{j = 42} \end{codeblock} -\exitexample +\end{example} \rSec2[stmt.ranged]{The range-based \tcode{for} statement}% \indextext{statement!range~based \idxcode{for}} @@ -575,18 +575,18 @@ \item otherwise, \textit{begin-expr} and \textit{end-expr} are \tcode{begin(__range)} and \tcode{end(__range)}, respectively, where \tcode{begin} and \tcode{end} are looked up in the associated namespaces~(\ref{basic.lookup.argdep}). -\enternote Ordinary unqualified lookup~(\ref{basic.lookup.unqual}) is not -performed. \exitnote +\begin{note} Ordinary unqualified lookup~(\ref{basic.lookup.unqual}) is not +performed. \end{note} \end{itemize} \end{itemize} -\enterexample +\begin{example} \begin{codeblock} int array[5] = { 1, 2, 3, 4, 5 }; for (int& x : array) x *= 2; \end{codeblock} -\exitexample% +\end{example}% \indextext{statement!iteration|)} \pnum @@ -621,14 +621,14 @@ \indextext{scope!destructor~and exit~from}% On exit from a scope (however accomplished), objects with automatic storage duration~(\ref{basic.stc.auto}) that have been constructed in that scope are destroyed -in the reverse order of their construction. \enternote For temporaries, -see~\ref{class.temporary}. \exitnote Transfer out of a loop, out of a block, or back +in the reverse order of their construction. \begin{note} For temporaries, +see~\ref{class.temporary}. \end{note} Transfer out of a loop, out of a block, or back past an initialized variable with automatic storage duration involves the destruction of objects with automatic storage duration that are in scope at the point transferred from but not at the point transferred to. (See~\ref{stmt.dcl} for transfers into blocks). -\enternote +\begin{note} However, the program can be terminated (by calling \indextext{\idxcode{exit}}% \indexlibrary{\idxcode{exit}}% @@ -637,7 +637,7 @@ \indexlibrary{\idxcode{abort}}% \tcode{std::abort()}~(\ref{support.start.term}), for example) without destroying class objects with automatic storage duration. -\exitnote +\end{note} \rSec2[stmt.break]{The \tcode{break} statement}% \indextext{statement!\idxcode{break}} @@ -720,20 +720,20 @@ \indextext{conversion!return~type}% the return statement initializes the object or reference to be returned by copy-initialization~(\ref{dcl.init}) from the operand. -\enternote +\begin{note} A return statement can involve the construction and copy or move of a temporary object~(\ref{class.temporary}). A copy or move operation associated with a return statement may be elided or considered as an rvalue for the purpose of overload resolution in selecting a constructor~(\ref{class.copy}). -\exitnote -\enterexample +\end{note} +\begin{example} \begin{codeblock} std::pair f(const char* p, int x) { return {p,x}; } \end{codeblock} -\exitexample +\end{example} Flowing off the end of a constructor, a destructor, or @@ -798,7 +798,7 @@ not in scope to a point where it is in scope is ill-formed unless the variable has scalar type, class type with a trivial default constructor and a trivial destructor, a cv-qualified version of one of these types, or an array of one of the preceding types and is declared without an \grammarterm{}{initializer}~(\ref{dcl.init}). -\enterexample +\begin{example} \begin{codeblock} void f() { @@ -814,7 +814,7 @@ // again immediately following label \tcode{ly} } \end{codeblock} -\exitexample +\end{example} \pnum \indextext{initialization!automatic}% @@ -830,7 +830,7 @@ complete, so it will be tried again the next time control enters the declaration. If control enters the declaration concurrently while the variable is being initialized, the concurrent execution shall wait for completion of the initialization.\footnote{The implementation must not introduce any deadlock around execution of the initializer.} If control re-enters the declaration recursively while the variable is being initialized, the behavior is undefined. -\enterexample +\begin{example} \begin{codeblock} int foo(int i) { @@ -838,16 +838,16 @@ return i+1; } \end{codeblock} -\exitexample +\end{example} \pnum \indextext{\idxcode{static}!destruction~of local}% The destructor for a block-scope object with static or thread storage duration will be executed if and only if it was constructed. -\enternote +\begin{note} \ref{basic.start.term} describes the order in which block-scope objects with static and thread storage duration are destroyed. -\exitnote +\end{note} \rSec1[stmt.ambig]{Ambiguity resolution}% \indextext{ambiguity!declaration~versus expression} @@ -862,14 +862,14 @@ \grammarterm{statement} is a \grammarterm{declaration}. \pnum -\enternote +\begin{note} If the \grammarterm{statement} cannot syntactically be a \grammarterm{declaration}, there is no ambiguity, so this rule does not apply. The whole \grammarterm{statement} might need to be examined to determine whether this is the case. This resolves the meaning of many examples. -\enterexample +\begin{example} Assuming \tcode{T} is a \grammarterm{simple-type-specifier}~(\ref{dcl.type}), @@ -887,10 +887,10 @@ In the last example above, \tcode{g}, which is a pointer to \tcode{T}, is initialized to \tcode{double(3)}. This is of course ill-formed for semantic reasons, but that does not affect the syntactic analysis. -\exitexample +\end{example} The remaining cases are \grammarterm{declaration}{s}. -\enterexample +\begin{example} \begin{codeblock} class T { @@ -907,8 +907,8 @@ extern int h; T(g)(h,2); // declaration \end{codeblock} -\exitexample -\exitnote +\end{example} +\end{note} \pnum The disambiguation is purely syntactic; that is, the meaning of the @@ -920,11 +920,11 @@ an ill-formed declaration. If, during parsing, a name in a template parameter is bound differently than it would be bound during a trial parse, the program is ill-formed. No diagnostic is required. -\enternote +\begin{note} This can occur only when the name is declared earlier in the declaration. -\exitnote -\enterexample +\end{note} +\begin{example} \begin{codeblock} struct T1 { @@ -947,5 +947,5 @@ // on \tcode{T2} being a type-name } \end{codeblock} -\exitexample% +\end{example}% \indextext{statement|)} diff --git a/source/strings.tex b/source/strings.tex index c78e6c55ed..e678be45e0 100644 --- a/source/strings.tex +++ b/source/strings.tex @@ -1709,7 +1709,7 @@ \tcode{capacity()} is greater or equal to the argument of \tcode{reserve}. -\enternote +\begin{note} Calling \tcode{reserve()} with a \tcode{res_arg} argument less than @@ -1718,7 +1718,7 @@ A call with \tcode{res_arg <= size()} is in effect a non-binding shrink-to-fit request. -\exitnote +\end{note} \pnum \throws @@ -1739,8 +1739,8 @@ \begin{itemdescr} \pnum \remarks \tcode{shrink_to_fit} is a non-binding request to reduce -\tcode{capacity()} to \tcode{size()}. \enternote The request is non-binding to -allow latitude for implementation-specific optimizations. \exitnote +\tcode{capacity()} to \tcode{size()}. \begin{note} The request is non-binding to +allow latitude for implementation-specific optimizations. \end{note} \end{itemdescr} \indexlibrary{\idxcode{basic_string}!\idxcode{clear}}% @@ -3523,8 +3523,8 @@ \pnum \returns \tcode{std::move(lhs.append(rhs))} -\enternote Or equivalently -\tcode{std::move(rhs.insert(0, lhs))} \exitnote +\begin{note} Or equivalently +\tcode{std::move(rhs.insert(0, lhs))} \end{note} \end{itemdescr} \indexlibrary{\idxcode{operator+}!\idxcode{basic_string}}% @@ -4381,9 +4381,9 @@ \tcode{wstring\{str, len\}}. \end{itemdescr} -\pnum \enternote +\pnum \begin{note} The same suffix \tcode{s} is used for \tcode{chrono::duration} literals denoting seconds but there is no conflict, since duration suffixes apply to numbers and string literal suffixes apply to character array literals. -\exitnote +\end{note} \rSec1[string.view]{String view classes} @@ -4392,10 +4392,10 @@ In the rest of this section, the type of the char-like objects held in a \tcode{basic_string_view} object is designated by \tcode{charT}. \pnum -\enternote +\begin{note} The library provides implicit conversions from \tcode{const charT*} and \tcode{std::basic_string} to \tcode{std::basic_string_view} so that user code can accept just \tcode{std::basic_string_view} as a non-templated parameter wherever a sequence of characters is expected. User-defined types should define their own implicit conversions to \tcode{std::basic_string_view} in order to interoperate with these functions. -\exitnote +\end{note} \pnum The complexity of \tcode{basic_string_view} member functions is O(1) unless otherwise specified. @@ -4799,10 +4799,10 @@ Nothing. \pnum -\enternote +\begin{note} Unlike \tcode{basic_string::operator[]}, \tcode{basic_string_view::operator[](size())} has undefined behavior instead of returning \tcode{charT()}. -\exitnote +\end{note} \end{itemdescr} \indexlibrary{\idxcode{basic_string_view}!\idxcode{at}}% @@ -4873,11 +4873,11 @@ \tcode{data_}. \pnum -\enternote +\begin{note} Unlike \tcode{basic_string::data()} and string literals, \tcode{data()} may return a pointer to a buffer that is not null-terminated. Therefore it is typically a mistake to pass \tcode{data()} to a routine that takes just a \tcode{const charT*} and expects a null-terminated string. -\exitnote +\end{note} \end{itemdescr} \rSec3[string.view.modifiers]{Modifiers} @@ -4945,9 +4945,9 @@ \bigoh{\tcode{size()}} \pnum -\enternote +\begin{note} Users who want to control the allocator instance should call \tcode{to_string(allocator)}. -\exitnote +\end{note} \end{itemdescr} \indexlibrary{\idxcode{basic_string_view}!\idxcode{to_string}}% @@ -5322,7 +5322,7 @@ \tcode{t >= sv} & \tcode{S(t) >= sv} \\ \tcode{sv >= t} & \tcode{sv >= S(t)} \\ \end{libtab2} -\enterexample +\begin{example} A sample conforming implementation for \tcode{operator==} would be: \begin{codeblock} template using __identity = decay_t; @@ -5342,7 +5342,7 @@ return lhs.compare(rhs) == 0; } \end{codeblock} -\exitexample +\end{example} \indexlibrary{\idxcode{operator==}!\idxcode{basic_string_view}}% \begin{itemdecl} diff --git a/source/support.tex b/source/support.tex index dd2eeed2a7..b0c3577f1c 100644 --- a/source/support.tex +++ b/source/support.tex @@ -110,11 +110,11 @@ to contain the size in bytes of any object. \pnum -\enternote +\begin{note} It is recommended that implementations choose types for \tcode{ptrdiff_t} and \tcode{size_t} whose integer conversion ranks~(\ref{conv.rank}) are no greater than that of \tcode{signed long int} unless a larger size is necessary to contain all the possible values. -\exitnote +\end{note} \pnum The type @@ -134,9 +134,9 @@ \end{codeblock} The type for which \tcode{nullptr_t} is a synonym has the characteristics -described in~\ref{basic.fundamental} and~\ref{conv.ptr}. \enternote Although +described in~\ref{basic.fundamental} and~\ref{conv.ptr}. \begin{note} Although \tcode{nullptr}'s address cannot be taken, the address of another -\tcode{nullptr_t} object that is an lvalue can be taken. \exitnote +\tcode{nullptr_t} object that is an lvalue can be taken. \end{note} \xref Alignment~(\ref{basic.align}), Sizeof~(\ref{expr.sizeof}), Additive operators~(\ref{expr.add}), Free store~(\ref{class.free}), and ISO C~7.1.6. @@ -752,8 +752,8 @@ \begin{itemdescr} \pnum True if the set of values representable by the type is finite.\footnote{Required by LIA-1.} -\enternote All fundamental types~(\ref{basic.fundamental}) are bounded. This member would be false for arbitrary -precision types.\exitnote +\begin{note} All fundamental types~(\ref{basic.fundamental}) are bounded. This member would be false for arbitrary +precision types.\end{note} \pnum Meaningful for all specializations. @@ -925,7 +925,7 @@ \tcode{false}. \pnum -\enterexample +\begin{example} \begin{codeblock} namespace std { template<> class numeric_limits { @@ -974,7 +974,7 @@ }; } \end{codeblock} -\exitexample +\end{example} \pnum The specialization for @@ -1082,9 +1082,9 @@ \pnum The contents are the same as the Standard C library header -\tcode{}. \enternote The types of the +\tcode{}. \begin{note} The types of the constants defined by macros in \tcode{} are not -required to match the types to which the macros refer.\exitnote +required to match the types to which the macros refer.\end{note} \pnum Table~\ref{tab:support.hdr.cfloat} describes the header @@ -1265,14 +1265,14 @@ \pnum The header defines all types and macros the same as -7.18 in the C standard. \enternote The macros defined +7.18 in the C standard. \begin{note} The macros defined by \tcode{} are provided unconditionally. In particular, the symbols \tcode{__STDC_LIMIT_MACROS} and \tcode{__STDC_CONSTANT_MACROS} (mentioned in footnotes -219, 220, and 222 in the C standard) play no role in \Cpp. \exitnote +219, 220, and 222 in the C standard) play no role in \Cpp. \end{note} \rSec1[support.start.term]{Start and termination} @@ -1358,8 +1358,8 @@ to be called without arguments at normal program termination. It is unspecified whether a call to \tcode{atexit()} that does not happen before~(\ref{intro.multithread}) a call to \tcode{exit()} will succeed. -\enternote The \tcode{atexit()} functions do not introduce a data -race~(\ref{res.on.data.races}). \exitnote +\begin{note} The \tcode{atexit()} functions do not introduce a data +race~(\ref{res.on.data.races}). \end{note} \pnum \implimits @@ -1453,17 +1453,17 @@ \effects The \tcode{at_quick_exit()} functions register the function pointed to by \tcode{f} to be called without arguments when \tcode{quick_exit} is called. It is unspecified whether a call to \tcode{at_quick_exit()} that does not -happen before~(\ref{intro.multithread}) all calls to \tcode{quick_exit} will succeed. \enternote The +happen before~(\ref{intro.multithread}) all calls to \tcode{quick_exit} will succeed. \begin{note} The \tcode{at_quick_exit()} functions do not introduce a -data race~(\ref{res.on.data.races}). \exitnote -\enternote +data race~(\ref{res.on.data.races}). \end{note} +\begin{note} The order of registration may be indeterminate if \tcode{at_quick_exit} was called from more than one thread. -\exitnote -\enternote The +\end{note} +\begin{note} The \tcode{at_quick_exit} registrations are distinct from the \tcode{atexit} registrations, and applications may need to call both registration functions with the same argument. -\exitnote +\end{note} \pnum \implimits @@ -1488,11 +1488,11 @@ function does not provide a handler for a thrown exception, \tcode{std::terminate()} shall be called.% \indexlibrary{\idxcode{terminate}} -\enternote \tcode{at_quick_exit} may call a registered function from a different thread +\begin{note} \tcode{at_quick_exit} may call a registered function from a different thread than the one that registered it, so registered functions should not rely on the identity -of objects with thread storage duration. \exitnote +of objects with thread storage duration. \end{note} After calling registered functions, \tcode{quick_exit} shall call \tcode{_Exit(status)}. -\enternote The standard file buffers are not flushed. \xsee ISO C~7.20.4.4. \exitnote +\begin{note} The standard file buffers are not flushed. \xsee ISO C~7.20.4.4. \end{note} \end{itemdescr} @@ -1654,12 +1654,12 @@ returns the result of that call. Otherwise, returns a null pointer. \pnum -\enterexample +\begin{example} \begin{codeblock} T* p1 = new T; // throws \tcode{bad_alloc} if it fails T* p2 = new(nothrow) T; // returns \tcode{nullptr} if it fails \end{codeblock} -\exitexample +\end{example} \end{itemdescr} \indexlibrary{\idxcode{delete}!\idxcode{operator}}% @@ -1687,9 +1687,9 @@ \tcode{void operator delete(void* ptr, std::size_t size) noexcept}. If this function with \tcode{size} parameter is defined, the program shall also define the version without the \tcode{size} parameter. -\enternote The default behavior below may change in the future, which will require +\begin{note} The default behavior below may change in the future, which will require replacing both deallocation functions when replacing the allocation function. -\exitnote +\end{note} \pnum \requires @@ -1715,14 +1715,14 @@ \pnum \required Calls to \tcode{operator delete(void* ptr, std::size_t size)} may be changed to calls to \tcode{operator delete(void* ptr)} without affecting memory allocation. -\enternote A conforming implementation is for +\begin{note} A conforming implementation is for \tcode{operator delete(void* ptr, std::size_t size)} to simply call -\tcode{operator delete(ptr)}. \exitnote +\tcode{operator delete(ptr)}. \end{note} \pnum \default the function \tcode{operator delete(void* ptr, std::size_t size)} calls \tcode{operator delete(ptr)}. -\enternote See the note in the above \textit{Replaceable} paragraph. \exitnote +\begin{note} See the note in the above \textit{Replaceable} paragraph. \end{note} \pnum \default @@ -1886,8 +1886,8 @@ \tcode{void operator delete[](void* ptr, std::size_t size) noexcept}. If this function with \tcode{size} parameter is defined, the program shall also define the version without the \tcode{size} parameter. -\enternote The default behavior below may change in the future, which will require -replacing both deallocation functions when replacing the allocation function. \exitnote +\begin{note} The default behavior below may change in the future, which will require +replacing both deallocation functions when replacing the allocation function. \end{note} \pnum \requires @@ -1907,9 +1907,9 @@ \pnum \required Calls to \tcode{operator delete[](void* ptr, std::size_t size)} may be changed to calls to \tcode{operator delete[](void* ptr)} without affecting memory allocation. -\enternote A conforming implementation is for +\begin{note} A conforming implementation is for \tcode{operator delete[](void* ptr, std::size_t size)} to simply call -\tcode{operator delete[](void* ptr)}. \exitnote +\tcode{operator delete[](void* ptr)}. \end{note} \pnum \requires @@ -1980,14 +1980,14 @@ Intentionally performs no other action. \pnum -\enterexample +\begin{example} This can be useful for constructing an object at a known address: \begin{codeblock} void* place = operator new(sizeof(Something)); Something* p = new (place) Something(); \end{codeblock} -\exitexample +\end{example} \end{itemdescr} \indexlibrary{\idxcode{new}!\idxcode{operator}}% @@ -2248,7 +2248,7 @@ \begin{itemdescr} \pnum \returns The current \tcode{new_handler}. -\enternote This may be a null pointer value. \exitnote +\begin{note} This may be a null pointer value. \end{note} \end{itemdescr} \rSec2[hardware.interference]{Hardware interference size} @@ -2264,14 +2264,14 @@ to avoid additional performance degradation due to contention introduced by the implementation. It shall be at least \tcode{alignof(max_align_t)}. -\enterexample +\begin{example} \begin{codeblock} struct keep_apart { alignas(hardware_destructive_interference_size) atomic cat; alignas(hardware_destructive_interference_size) atomic dog; }; \end{codeblock} -\exitexample +\end{example} \indexlibrary{\idxcode{hardware_constructive_interference_size}}% \begin{codeblock} @@ -2283,7 +2283,7 @@ occupied by two objects accessed with temporal locality by concurrent threads. It shall be at least \tcode{alignof(max_align_t)}. -\enterexample +\begin{example} \begin{codeblock} struct together { atomic dog; @@ -2296,7 +2296,7 @@ }; static_assert(sizeof(together) <= hardware_constructive_interference_size); \end{codeblock} -\exitexample +\end{example} \rSec1[support.rtti]{Type identification} @@ -2836,7 +2836,7 @@ \begin{itemdescr} \pnum \returns The current \tcode{terminate_handler}. -\enternote This may be a null pointer value. \exitnote +\begin{note} This may be a null pointer value. \end{note} \end{itemdescr} \rSec3[terminate]{\tcode{terminate}} @@ -2858,9 +2858,9 @@ Calls a \tcode{terminate_handler} function. It is unspecified which \tcode{terminate_handler} function will be called if an exception is active during a call to \tcode{set_terminate}. -Otherwise calls the current \tcode{terminate_handler} function. \enternote A +Otherwise calls the current \tcode{terminate_handler} function. \begin{note} A default \tcode{terminate_handler} is always considered a callable handler in -this context. \exitnote +this context. \end{note} \end{itemdescr} \rSec2[uncaught.exceptions]{\tcode{uncaught_exceptions}} @@ -2910,19 +2910,19 @@ enumeration, or pointer type. \pnum -\enternote An implementation might use a reference-counted smart -pointer as \tcode{exception_ptr}. \exitnote +\begin{note} An implementation might use a reference-counted smart +pointer as \tcode{exception_ptr}. \end{note} \pnum For purposes of determining the presence of a data race, operations on \tcode{exception_ptr} objects shall access and modify only the \tcode{exception_ptr} objects themselves and not the exceptions they refer to. Use of \tcode{rethrow_exception} on \tcode{exception_ptr} objects that refer to -the same exception object shall not introduce a data race. \enternote if +the same exception object shall not introduce a data race. \begin{note} if \tcode{rethrow_exception} rethrows the same exception object (rather than a copy), concurrent access to that rethrown exception object may introduce a data race. Changes in the number of \tcode{exception_ptr} objects that refer to a -particular exception do not introduce a data race. \exitnote +particular exception do not introduce a data race. \end{note} \end{itemdescr} \indexlibrary{\idxcode{current_exception}} @@ -2941,14 +2941,14 @@ \tcode{exception_ptr} object that refers to an instance of \tcode{bad_alloc}. It is unspecified whether the return values of two successive calls to \tcode{current_exception} refer to the same exception object. -\enternote That is, it is unspecified whether \tcode{current_exception} -creates a new copy each time it is called. \exitnote +\begin{note} That is, it is unspecified whether \tcode{current_exception} +creates a new copy each time it is called. \end{note} If the attempt to copy the current exception object throws an exception, the function returns an \tcode{exception_ptr} object that refers to the thrown exception or, -if this is not possible, to an instance of \tcode{bad_exception}. \enternote The +if this is not possible, to an instance of \tcode{bad_exception}. \begin{note} The copy constructor of the thrown exception may also fail, so the implementation is allowed to substitute a \tcode{bad_exception} object to avoid infinite -recursion.\exitnote +recursion.\end{note} \end{itemdescr} \indexlibrary{\idxcode{rethrow_exception}} @@ -2981,8 +2981,8 @@ \end{codeblock} \pnum -\enternote This function is provided for convenience and -efficiency reasons. \exitnote +\begin{note} This function is provided for convenience and +efficiency reasons. \end{note} \end{itemdescr} \rSec2[except.nested]{\tcode{nested_exception}} @@ -3013,9 +3013,9 @@ for later use. \pnum -\enternote \tcode{nested_exception} has a virtual destructor to make it a +\begin{note} \tcode{nested_exception} has a virtual destructor to make it a polymorphic class. Its presence can be tested for with \tcode{dynamic_cast}. -\exitnote +\end{note} \indexlibrary{\idxcode{nested_exception}!\idxcode{nested_exception}} \indexlibrary{\idxcode{nested_exception}!\idxcode{nested_exception}} @@ -3225,11 +3225,11 @@ \pnum An object of type \tcode{initializer_list} provides access to an array of -objects of type \tcode{const E}. \enternote A pair of pointers or a pointer plus +objects of type \tcode{const E}. \begin{note} A pair of pointers or a pointer plus a length would be obvious representations for \tcode{initializer_list}. \tcode{initializer_list} is used to implement initializer lists as specified in~\ref{dcl.init.list}. Copying an initializer list does not copy the underlying -elements. \exitnote +elements. \end{note} \pnum If an explicit specialization or partial specialization of @@ -3398,12 +3398,12 @@ \indexlibrary{\idxcode{getenv}}% \tcode{getenv} shall not introduce a data race~(\ref{res.on.data.races}) provided that nothing modifies the environment. -\enternote Calls to the POSIX functions +\begin{note} Calls to the POSIX functions \indexlibrary{\idxcode{setenv}}% \tcode{setenv} and \indexlibrary{\idxcode{putenv}}% \tcode{putenv} modify the -environment. \exitnote +environment. \end{note} \pnum A call to the \tcode{setlocale} function may introduce a data race with other diff --git a/source/templates.tex b/source/templates.tex index cd8f89dc66..f2f776fdf5 100644 --- a/source/templates.tex +++ b/source/templates.tex @@ -25,12 +25,12 @@ template-parameter-list \terminal{,} template-parameter \end{bnf} -\enternote The \tcode{>} token following the +\begin{note} The \tcode{>} token following the \nonterminal{template-parameter-list} of a \nonterminal{template-declaration} may be the product of replacing a \tcode{>{>}} token by two consecutive \tcode{>} -tokens~(\ref{temp.names}).\exitnote +tokens~(\ref{temp.names}).\end{note} The \grammarterm{declaration} @@ -60,7 +60,7 @@ variable is a \term{variable template}. A variable template at class scope is a \term{static data member template}. -\enterexample +\begin{example} \begin{codeblock} template constexpr T pi = T(3.1415926535897932385L); @@ -79,7 +79,7 @@ constexpr pauli sigma3 = { { 1, 0 }, { 0, -1 } }; }; \end{codeblock} -\exitexample +\end{example} \pnum A @@ -89,7 +89,7 @@ \grammarterm{declarator-id} shall not be a \grammarterm{template-id}. -\enternote +\begin{note} That last component may be an \grammarterm{identifier}, an \grammarterm{operator-function-id}, a \grammarterm{conversion-function-id}, or a \grammarterm{literal-operator-id}. In a class template declaration, if the @@ -97,7 +97,7 @@ is a \grammarterm{simple-template-id}, the declaration declares a class template partial specialization~(\ref{temp.class.spec}). -\exitnote +\end{note} \pnum In a @@ -121,11 +121,11 @@ conditionally-supported, with \impldef{semantics of linkage specification on templates} semantics. Template definitions shall obey the one-definition rule~(\ref{basic.def.odr}). -\enternote +\begin{note} Default arguments for function templates and for member functions of class templates are considered definitions for the purpose of template instantiation~(\ref{temp.decls}) and must also obey the one-definition rule. -\exitnote +\end{note} \pnum A class template shall not have the same name as any other @@ -172,12 +172,12 @@ \terminal{typename} \end{bnf} -\enternote The \tcode{>} token following the +\begin{note} The \tcode{>} token following the \nonterminal{template-parameter-list} of a \nonterminal{type-parameter} may be the product of replacing a \tcode{>{>}} token by two consecutive \tcode{>} -tokens~(\ref{temp.names}).\exitnote +tokens~(\ref{temp.names}).\end{note} \pnum There is no semantic difference between @@ -206,7 +206,7 @@ \grammarterm{parameter-declaration}. A \grammarterm{template-parameter} of the form \tcode{class} \grammarterm{identifier} is a \grammarterm{type-parameter}. -\enterexample +\begin{example} \begin{codeblock} class T { /* ... */ }; int i; @@ -220,7 +220,7 @@ Here, the template \tcode{f} has a \grammarterm{type-parameter} called \tcode{T}, rather than an unnamed non-type \grammarterm{template-parameter} of class \tcode{T}. -\exitexample +\end{example} A storage class shall not be specified in a \grammarterm{template-parameter} declaration. @@ -242,7 +242,7 @@ (if declared with \tcode{template}) in the scope of the template declaration. -\enternote +\begin{note} A template argument may be a class template or alias template. For example, @@ -255,7 +255,7 @@ C value; }; \end{codeblock} -\exitnote +\end{note} \pnum A non-type @@ -277,11 +277,11 @@ \end{itemize} \pnum -\enternote +\begin{note} Other types are disallowed either explicitly below or implicitly by the rules governing the form of \grammarterm{template-argument}{s}~(\ref{temp.arg}). -\exitnote +\end{note} The top-level \grammarterm{cv-qualifiers} on the @@ -299,7 +299,7 @@ When a non-type non-reference \grammarterm{template-parameter} is used as an initializer for a reference, a temporary is always used. -\enterexample +\begin{example} \begin{codeblock} template void f() { @@ -312,20 +312,20 @@ const int& cri = i; // OK: const reference bound to temporary } \end{codeblock} -\exitexample +\end{example} \pnum A non-type \grammarterm{template-parameter} shall not be declared to have floating point, class, or void type. -\enterexample +\begin{example} \begin{codeblock} template class X; // error template class Y; // OK template class Z; // OK \end{codeblock} -\exitexample +\end{example} \pnum A non-type @@ -335,7 +335,7 @@ \indextext{function!template parameter~of~type}% of function type \tcode{T} is adjusted to be of type ``pointer to \tcode{T}''. -\enterexample +\begin{example} \begin{codeblock} template struct R { /* ... */ }; @@ -347,7 +347,7 @@ R y; // OK due to implicit argument conversion S z; // OK due to both adjustment and conversion \end{codeblock} -\exitexample +\end{example} \pnum A @@ -387,7 +387,7 @@ available for use is obtained by merging the default arguments from all prior declarations of the template in the same way default function arguments are~(\ref{dcl.fct.default}). -\enterexample +\begin{example} \begin{codeblock} template class A; @@ -399,7 +399,7 @@ \begin{codeblock} template class A; \end{codeblock} -\exitexample +\end{example} \pnum If a @@ -420,7 +420,7 @@ template parameter unless that template parameter can be deduced from the \grammarterm{parameter-type-list} of the function template or has a default argument~(\ref{temp.deduct}). -\enterexample +\begin{example} \begin{codeblock} template class B; // error @@ -429,20 +429,20 @@ template void f() { } // error template void g() { } // error \end{codeblock} -\exitexample +\end{example} \pnum A \grammarterm{template-parameter} shall not be given default arguments by two different declarations in the same scope. -\enterexample +\begin{example} \begin{codeblock} template class X; template class X { /*... */ }; // error \end{codeblock} -\exitexample +\end{example} \indextext{\idxcode{<}!template~and}% \pnum @@ -456,7 +456,7 @@ is taken as the end of the \grammarterm{template-parameter-list} rather than a greater-than operator. -\enterexample +\begin{example} \begin{codeblock} template 4 > // syntax error @@ -465,7 +465,7 @@ template 4) > // OK class Y { /* ... */ }; \end{codeblock} -\exitexample +\end{example} \pnum A @@ -478,7 +478,7 @@ \grammarterm{template-parameter} in the scope of the template \grammarterm{template-parameter}. -\enterexample +\begin{example} \begin{codeblock} template struct B {}; template