Avoid \pnum inside examples. (#1262)

With the exception of [facets.examples].

Fixes #781.

Author: jensmaurer

source/access.tex

@@ -116,8 +116,9 @@
 the class appearing outside the class's \grammarterm{member-specification}{.}
 \begin{note} This access also applies to implicit references to constructors,
 conversion functions, and destructors. \end{note}
-\begin{example}
 
+\pnum
+\begin{example}
 \begin{codeblock}
 class A {
   typedef int I;    // private member
@@ -140,7 +141,6 @@
 struct D: A::B, A { };
 \end{codeblock}
 
-\pnum
 Here, all the uses of
 \tcode{A::I}
 are well-formed because
@@ -968,7 +968,6 @@
 };
 \end{codeblock}
 
-\pnum
 Since
 \tcode{W::f()}
 is available to

source/basic.tex

@@ -1843,11 +1843,13 @@
                     // overload resolution chooses \tcode{Z::h(double)}
 }
 \end{codeblock}
+\end{example}
 
 \pnum
+\begin{note}
 The same declaration found more than once is not an ambiguity (because
-it is still a unique declaration). For example:
-
+it is still a unique declaration).
+\begin{example}
 \begin{codeblock}
 namespace A {
   int a;
@@ -1885,8 +1887,11 @@
   BD::a++;          // OK: \tcode{S} is $\{ \text{\tcode{A::a}}, \text{\tcode{A::a}} \}$
 }
 \end{codeblock}
+\end{example}
+\end{note}
 
 \pnum
+\begin{example}
 Because each referenced namespace is searched at most once, the
 following is well-defined:
 

source/declarations.tex

@@ -3918,14 +3918,12 @@
 }
 \end{codeblock}
 
-\pnum
 The \tcode{carries_dependency} attribute on function \tcode{f} means that the
 return value carries a dependency out of \tcode{f}, so that the implementation
 need not constrain ordering upon return from \tcode{f}. Implementations of
 \tcode{f} and its caller may choose to preserve dependencies instead of emitting
 hardware memory ordering instructions (a.k.a. fences).
 
-\pnum
 Function \tcode{g}'s second parameter has a \tcode{carries_dependency} attribute,
 but its first parameter does not. Therefore, function \tcode{h}'s first call to
 \tcode{g} carries a dependency into \tcode{g}, but its second call does not. The

source/derived.tex

@@ -239,8 +239,10 @@
 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.
-\begin{example}
-for an object of class type \tcode{C}, each distinct occurrence of a
+
+\pnum
+\begin{note}
+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
 object of type \tcode{C}. Given the class \tcode{C} defined above, an
@@ -253,7 +255,6 @@
 {fignonvirt.pdf}
 \end{importgraphic}
 
-\pnum
 In such lattices, explicit qualification can be used to specify which
 subobject is meant. The body of function \tcode{C::f} could refer to the
 member \tcode{next} of each \tcode{L} subobject:
@@ -263,31 +264,33 @@
 Without the \tcode{A::} or \tcode{B::} qualifiers, the definition of
 \tcode{C::f} above would be ill-formed because of
 ambiguity~(\ref{class.member.lookup}).
+\end{note}
 
 \pnum
-For another example,
+\begin{note}
+In contrast, consider the case with a virtual base class:
 \begin{codeblock}
 class V { @\commentellip@ };
 class A : virtual public V { @\commentellip@ };
 class B : virtual public V { @\commentellip@ };
 class C : public A, public B { @\commentellip@ };
 \end{codeblock}
-for an object \tcode{c} of class type \tcode{C}, a single subobject of
+\begin{importgraphic}
+{Virtual base}
+{fig:virt}
+{figvirt.pdf}
+\end{importgraphic}
+For an object \tcode{c} of class type \tcode{C}, a single subobject of
 type \tcode{V} is shared by every base subobject of \tcode{c} that has a
 \tcode{virtual} base class of type \tcode{V}. Given the class \tcode{C}
 defined above, an object of class \tcode{C} will have one subobject of
 class \tcode{V}, as shown in Figure~\ref{fig:virt}.
-
 \indextext{DAG!multiple inheritance}%
 \indextext{DAG!virtual base class}%
-\begin{importgraphic}
-{Virtual base}
-{fig:virt}
-{figvirt.pdf}
-\end{importgraphic}
-
+\end{note}
 
 \pnum
+\begin{note}
 A class can have both virtual and non-virtual base classes of a given
 type.
 \begin{codeblock}
@@ -315,8 +318,7 @@
 {fig:virtnonvirt}
 {figvirtnonvirt.pdf}
 \end{importgraphic}
-
-\end{example}
+\end{note}
 
 \rSec1[class.member.lookup]{Member name lookup}%
 \indextext{lookup!member name}%

source/iostreams.tex

@@ -12067,17 +12067,14 @@
 fs::create_directory(fs::u8path(utf8_string));
 \end{codeblock}
 
-\pnum
 For POSIX-based operating systems with the native narrow encoding set
     to UTF-8, no encoding or type conversion occurs.
 
-\pnum
 For POSIX-based operating systems with the native narrow encoding not
     set to UTF-8, a conversion to UTF-32 occurs, followed by a conversion to the
     current native narrow encoding. Some Unicode characters may have no native character
     set representation.
 
-\pnum
 For Windows-based operating systems a conversion from UTF-8 to
     UTF-16 occurs.
 \end{example}
@@ -13443,7 +13440,6 @@
     file3
 \end{codeblock}
 
-\pnum
 Calling \tcode{copy("/dir1", "/dir3")} would result in:
 \begin{codeblock}
 /dir1
@@ -13456,7 +13452,6 @@
   file2
 \end{codeblock}
 
-\pnum
 Alternatively, calling \tcode{copy("/dir1", "/dir3", copy_options::recursive)} would result in:
 \begin{codeblock}
 /dir1
@@ -14691,7 +14686,6 @@
 \begin{example} For POSIX-based operating systems, \tcode{system_complete(p)}
   has the same semantics as \tcode{absolute(p, current_path())}.
 
-\pnum
 For Windows-based operating systems, \tcode{system_complete(p)} has the
   same semantics as \tcode{absolute(p, current_path())} if
   \tcode{p.is_absolute() || !p.has_root_name()} or
@@ -14729,7 +14723,6 @@
   supplied by the first environment variable found in the list TMPDIR, TMP, TEMP, TEMPDIR,
   or if none of these are found, \tcode{"/tmp"}.
 
-\pnum
 For Windows-based operating systems, an implementation might return the path
   reported by the Windows \tcode{GetTempPath} API function.
 \end{example}

source/statements.tex

@@ -475,7 +475,6 @@
 }
 \end{codeblock}
 
-\pnum
 Thus after the \tcode{while} statement, \tcode{i} is no longer in scope.
 \end{example}
 

source/templates.tex

@@ -7513,6 +7513,7 @@
 be given preference over a template specialization if the two functions
 are otherwise equally good candidates for an overload match.}
 
+\pnum
 \begin{example}
 \begin{codeblock}
 template<class T> T max(T a, T b) { return a>b?a:b; }
@@ -7524,7 +7525,6 @@
 }
 \end{codeblock}
 
-\pnum
 Adding the non-template function
 
 \begin{codeblock}
@@ -7540,8 +7540,10 @@
 \tcode{int}
 for
 \tcode{c}.
+\end{example}
 
 \pnum
+\begin{example}
 Here is an example involving conversions on a function argument involved in
 \grammarterm{template-argument}
 deduction:
@@ -7556,8 +7558,10 @@
   f(di);            // \tcode{f((B<int>\&)di)}
 }
 \end{codeblock}
+\end{example}
 
 \pnum
+\begin{example}
 Here is an example involving conversions on a function argument not involved in
 \grammarterm{template-parameter}
 deduction:
@@ -7591,7 +7595,6 @@
 }
 \end{codeblock}
 
-\pnum
 The call of
 \tcode{f}
 is well-formed even if the template