[lib] Remove 'std::' prefix from library names. (#1085)

The standard library specifies that references to its names are assumed to be prefixed by '::std::'. Therefore, we can remove any explicit 'std::' prefixes.

[iterator.range] was not touched, because it is unclear whether argument-dependent lookup was intended to be disabled here.

Fixes #431.

Author: jensmaurer

source/algorithms.tex

@@ -1274,11 +1274,11 @@
 permitted to execute in either the invoking thread of execution or in a
 thread of execution implicitly
 created by the library to support parallel algorithm execution.
-If the threads of execution created by \tcode{std::thread} provide concurrent
+If the threads of execution created by \tcode{thread}~(\ref{thread.thread.class}) provide concurrent
 forward progress guarantees~(\ref{intro.progress}), then a thread of execution
 implicitly created by the library will provide parallel forward progress guarantees;
 otherwise, the provided forward progress guarantee is
-\impldef{forward progress guarantees for implicit threads of parallel algorithms (if not defined for \tcode{std::thread})}.
+\impldef{forward progress guarantees for implicit threads of parallel algorithms (if not defined for \tcode{thread})}.
 Any such
 invocations executing in the same thread of execution are indeterminately sequenced with
 respect to each other.

source/atomics.tex

@@ -816,7 +816,7 @@
 \item a \textit{C} refers to its corresponding non-atomic type.
 \item an \textit{M} refers to type of the other argument for arithmetic operations. For
 integral atomic types, \textit{M} is \textit{C}. For atomic address types, \textit{M} is
-\tcode{std::ptrdiff_t}.
+\tcode{ptrdiff_t}.
 \item the non-member functions not ending in \tcode{_explicit} have the semantics of their
 corresponding \tcode{_explicit} functions with \tcode{memory_order} arguments of
 \tcode{memory_order_seq_cst}.

source/containers.tex

@@ -528,8 +528,8 @@
 and an rvalue \tcode{rv} of type \tcode{T},
 the following terms are defined. If \tcode{X}
 is not allocator-aware, the terms below are defined as if \tcode{A} were
-\tcode{std::allocator<T>} --- no allocator object needs to be created
-and user specializations of \tcode{std::allocator<T>} are not instantiated:
+\tcode{allocator<T>} --- no allocator object needs to be created
+and user specializations of \tcode{allocator<T>} are not instantiated:
 
 \begin{itemize}
 \item
@@ -596,7 +596,7 @@
 A container calls \tcode{allocator_traits<A>::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
+The default \tcode{construct} in \tcode{allocator} will
 call \tcode{::new((void*)p) T(args)},
 but specialized allocators may choose a different definition.
 \end{note}
@@ -765,7 +765,7 @@
 \tcode{A} denotes \tcode{X::allocator_type} if
 the \grammarterm{qualified-id} \tcode{X::allocator_type} is valid and denotes a
 type~(\ref{temp.deduct}) and
-\tcode{std::allocator<T>} if it doesn't,
+\tcode{allocator<T>} if it doesn't,
 \tcode{i} and \tcode{j}
 denote iterators satisfying input iterator requirements
 and refer to elements implicitly convertible to \tcode{value_type},
@@ -1222,7 +1222,7 @@
 this name.
 
 \pnum
-If a user-defined specialization of \tcode{std::pair} exists for
+If a user-defined specialization of \tcode{pair} exists for
 \tcode{pair<const Key, T>} or \tcode{pair<Key, T>}, where \tcode{Key} is the
 container's \tcode{key_type} and \tcode{T} is the container's
 \tcode{mapped_type}, the behavior of operations involving node handles is
@@ -1579,7 +1579,7 @@
 \tcode{ke} is a value such that \tcode{a} is partitioned with respect to
 \tcode{c(r, ke)} and \tcode{!c(ke, r)}, with \tcode{c(r, ke)} implying
 \tcode{!c(ke, r)}.
-\tcode{A} denotes the storage allocator used by \tcode{X}, if any, or \tcode{std::allocator<X::value_type>} otherwise,
+\tcode{A} denotes the storage allocator used by \tcode{X}, if any, or \tcode{allocator<X::value_type>} otherwise,
 \tcode{m} denotes an allocator of a type convertible to \tcode{A},
 and \tcode{nh} denotes a non-const rvalue of type \tcode{X::node_type}.
 
@@ -2112,7 +2112,7 @@
 \pnum
 For \tcode{unordered_set} and \tcode{unordered_multiset} the value type is
 the same as the key type.  For \tcode{unordered_map} and
-\tcode{unordered_multimap} it is \tcode{std::pair<const Key,
+\tcode{unordered_multimap} it is \tcode{pair<const Key,
 T>}.
 
 \pnum
@@ -2218,7 +2218,7 @@
 \tcode{X::hasher}
 &   \tcode{Hash}
 &   \tcode{Hash} shall be a unary function object type such that the expression
-    \tcode{hf(k)} has type \tcode{std::size_t}.%
+    \tcode{hf(k)} has type \tcode{size_t}.%
     \indextext{unordered associative containers!\idxcode{hasher}}%
     \indextext{\idxcode{hasher}!unordered associative containers}%
 &   compile time
@@ -6266,7 +6266,7 @@
 \pnum
 \remarks
 These signatures shall not participate in overload resolution
-unless \tcode{std::is_constructible_v<value_type, P\&\&>} is
+unless \tcode{is_constructible_v<value_type, P\&\&>} is
 \tcode{true}.
 \end{itemdescr}
 
@@ -6722,7 +6722,7 @@
 \pnum
 \remarks
 These signatures shall not participate in overload resolution
-unless \tcode{std::is_constructible_v<value_type, P\&\&>} is
+unless \tcode{is_constructible_v<value_type, P\&\&>} is
 \tcode{true}.
 \end{itemdescr}
 
@@ -7300,16 +7300,16 @@
   template <class Key,
             class T,
             class Hash = hash<Key>,
-            class Pred = std::equal_to<Key>,
-            class Alloc = std::allocator<std::pair<const Key, T>>>
+            class Pred = equal_to<Key>,
+            class Alloc = allocator<pair<const Key, T>>>
     class unordered_map;
 
   // \ref{unord.multimap}, class template unordered_multimap
   template <class Key,
             class T,
             class Hash = hash<Key>,
-            class Pred = std::equal_to<Key>,
-            class Alloc = std::allocator<std::pair<const Key, T>>>
+            class Pred = equal_to<Key>,
+            class Alloc = allocator<pair<const Key, T>>>
     class unordered_multimap;
 
   template <class Key, class T, class Hash, class Pred, class Alloc>
@@ -7366,15 +7366,15 @@
   // \ref{unord.set}, class template unordered_set
   template <class Key,
             class Hash = hash<Key>,
-            class Pred = std::equal_to<Key>,
-            class Alloc = std::allocator<Key>>
+            class Pred = equal_to<Key>,
+            class Alloc = allocator<Key>>
     class unordered_set;
 
   // \ref{unord.multiset}, class template unordered_multiset
   template <class Key,
             class Hash = hash<Key>,
-            class Pred = std::equal_to<Key>,
-            class Alloc = std::allocator<Key>>
+            class Pred = equal_to<Key>,
+            class Alloc = allocator<Key>>
     class unordered_multiset;
 
   template <class Key, class Hash, class Pred, class Alloc>
@@ -7432,7 +7432,7 @@
 supports forward iterators.
 
 \pnum
-An \tcode{unordered_map} satisfies all of the requirements of a container, of an unordered associative container, and of an allocator-aware container (Table~\ref{tab:containers.allocatoraware}). It provides the operations described in the preceding requirements table for unique keys; that is, an \tcode{unordered_map} supports the \tcode{a_uniq} operations in that table, not the \tcode{a_eq} operations. For an \tcode{unordered_map<Key, T>} the \tcode{key type} is \tcode{Key}, the mapped type is \tcode{T}, and the value type is \tcode{std::pair<const Key, T>}.
+An \tcode{unordered_map} satisfies all of the requirements of a container, of an unordered associative container, and of an allocator-aware container (Table~\ref{tab:containers.allocatoraware}). It provides the operations described in the preceding requirements table for unique keys; that is, an \tcode{unordered_map} supports the \tcode{a_uniq} operations in that table, not the \tcode{a_eq} operations. For an \tcode{unordered_map<Key, T>} the \tcode{key type} is \tcode{Key}, the mapped type is \tcode{T}, and the value type is \tcode{pair<const Key, T>}.
 
 \pnum
 This section only describes operations on \tcode{unordered_map} that
@@ -7445,8 +7445,8 @@
   template <class Key,
             class T,
             class Hash = hash<Key>,
-            class Pred = std::equal_to<Key>,
-            class Allocator = std::allocator<std::pair<const Key, T>>>
+            class Pred = equal_to<Key>,
+            class Allocator = allocator<pair<const Key, T>>>
   class unordered_map {
   public:
     // types:
@@ -7591,8 +7591,8 @@
     iterator       find(const key_type& k);
     const_iterator find(const key_type& k) const;
     size_type      count(const key_type& k) const;
-    std::pair<iterator, iterator>             equal_range(const key_type& k);
-    std::pair<const_iterator, const_iterator> equal_range(const key_type& k) const;
+    pair<iterator, iterator>             equal_range(const key_type& k);
+    pair<const_iterator, const_iterator> equal_range(const key_type& k) const;
 
     // \ref{unord.map.elem}, element access
     mapped_type& operator[](const key_type& k);
@@ -7743,7 +7743,7 @@
 
 \pnum
 \remarks This signature shall not participate in overload resolution
-unless \tcode{std::is_constructible_v<value_type, P\&\&>} is \tcode{true}.
+unless \tcode{is_constructible_v<value_type, P\&\&>} is \tcode{true}.
 \end{itemdescr}
 
 \indexlibrarymember{unordered_map}{insert}%
@@ -7759,7 +7759,7 @@
 
 \pnum
 \remarks This signature shall not participate in overload resolution
-unless \tcode{std::is_constructible_v<value_type, P\&\&>} is \tcode{true}.
+unless \tcode{is_constructible_v<value_type, P\&\&>} is \tcode{true}.
 \end{itemdescr}
 
 \indexlibrarymember{try_emplace}{unordered_map}%
@@ -7940,7 +7940,7 @@
 preceding requirements table for equivalent keys; that is, an \tcode{unordered_multimap}
 supports the \tcode{a_eq} operations in that table, not the \tcode{a_uniq} operations.
 For an \tcode{unordered_multimap<Key, T>} the \tcode{key type} is \tcode{Key}, the
-mapped type is \tcode{T}, and the value type is \tcode{std::pair<const Key, T>}.
+mapped type is \tcode{T}, and the value type is \tcode{pair<const Key, T>}.
 
 \pnum
 This section only describes operations on \tcode{unordered_multimap}
@@ -7953,8 +7953,8 @@
   template <class Key,
             class T,
             class Hash = hash<Key>,
-            class Pred = std::equal_to<Key>,
-            class Allocator = std::allocator<std::pair<const Key, T>>>
+            class Pred = equal_to<Key>,
+            class Allocator = allocator<pair<const Key, T>>>
   class unordered_multimap {
   public:
     // types:
@@ -8081,8 +8081,8 @@
     iterator       find(const key_type& k);
     const_iterator find(const key_type& k) const;
     size_type      count(const key_type& k) const;
-    std::pair<iterator, iterator>             equal_range(const key_type& k);
-    std::pair<const_iterator, const_iterator> equal_range(const key_type& k) const;
+    pair<iterator, iterator>             equal_range(const key_type& k);
+    pair<const_iterator, const_iterator> equal_range(const key_type& k) const;
 
     // bucket interface:
     size_type bucket_count() const noexcept;
@@ -8189,7 +8189,7 @@
 
 \pnum
 \remarks This signature shall not participate in overload resolution
-unless \tcode{std::is_constructible_v<value_type, P\&\&>} is \tcode{true}.
+unless \tcode{is_constructible_v<value_type, P\&\&>} is \tcode{true}.
 \end{itemdescr}
 
 \indexlibrarymember{unordered_multimap}{insert}%
@@ -8205,7 +8205,7 @@
 
 \pnum
 \remarks This signature shall not participate in overload resolution
-unless \tcode{std::is_constructible_v<value_type, P\&\&>} is \tcode{true}.
+unless \tcode{is_constructible_v<value_type, P\&\&>} is \tcode{true}.
 \end{itemdescr}
 
 \rSec3[unord.multimap.swap]{\tcode{unordered_multimap} swap}
@@ -8251,8 +8251,8 @@
 namespace std {
   template <class Key,
             class Hash = hash<Key>,
-            class Pred = std::equal_to<Key>,
-            class Allocator = std::allocator<Key>>
+            class Pred = equal_to<Key>,
+            class Allocator = allocator<Key>>
   class unordered_set {
   public:
     // types:
@@ -8377,8 +8377,8 @@
     iterator       find(const key_type& k);
     const_iterator find(const key_type& k) const;
     size_type      count(const key_type& k) const;
-    std::pair<iterator, iterator>             equal_range(const key_type& k);
-    std::pair<const_iterator, const_iterator> equal_range(const key_type& k) const;
+    pair<iterator, iterator>             equal_range(const key_type& k);
+    pair<const_iterator, const_iterator> equal_range(const key_type& k) const;
 
     // bucket interface:
     size_type bucket_count() const noexcept;
@@ -8519,8 +8519,8 @@
 namespace std {
   template <class Key,
             class Hash = hash<Key>,
-            class Pred = std::equal_to<Key>,
-            class Allocator = std::allocator<Key>>
+            class Pred = equal_to<Key>,
+            class Allocator = allocator<Key>>
   class unordered_multiset {
   public:
     // types:
@@ -8644,8 +8644,8 @@
     iterator       find(const key_type& k);
     const_iterator find(const key_type& k) const;
     size_type      count(const key_type& k) const;
-    std::pair<iterator, iterator>             equal_range(const key_type& k);
-    std::pair<const_iterator, const_iterator> equal_range(const key_type& k) const;
+    pair<iterator, iterator>             equal_range(const key_type& k);
+    pair<const_iterator, const_iterator> equal_range(const key_type& k) const;
 
     // bucket interface:
     size_type bucket_count() const noexcept;

source/iostreams.tex

@@ -6531,9 +6531,9 @@
 and the second is of type
 \tcode{const char*},
 \item
-\tcode{std::char_traits<char>::length(s)}
+\tcode{char_traits<char>::length(s)}
 for the overload where the first argument is of type
-\tcode{basic_ostream<\brk{}charT, traits>\&}
+\tcode{basic_ostream<charT, traits>\&}
 and the second is of type
 \tcode{const char*},
 \item
@@ -8714,7 +8714,7 @@
 It then opens a file, if possible, whose name is the
 \ntbs \tcode{s}
 (as if by calling
-\tcode{std::fopen(s, modstr)}).
+\tcode{fopen(s, modstr)}).
 \indextext{NTBS}%
 \indexlibrary{\idxcode{fopen}}%
 The \ntbs \tcode{modstr} is determined from
@@ -8753,7 +8753,7 @@
 \tcode{(mode \& ios_base::ate) != 0},
 positions the file to the end
 (as if by calling
-\tcode{std::fseek(file, 0, SEEK_END)}).\footnote{The macro
+\tcode{fseek(file, 0, SEEK_END)}).\footnote{The macro
 \tcode{SEEK_END}
 is defined, and the function signatures
 \indexlibrary{\idxcode{fopen}}%
@@ -9089,9 +9089,9 @@
 Next, seek to the new position: if
 \tcode{width > 0},
 call
-\tcode{std::fseek(file, width * off, whence)},
+\tcode{fseek(file, width * off, whence)},
 otherwise call
-\tcode{std::fseek(file, 0, whence)}.
+\tcode{fseek(file, 0, whence)}.
 
 \pnum
 \remarks

source/lib-intro.tex

@@ -2121,7 +2121,7 @@
 fail. The allocator also may silently ignore the requested alignment.
 \begin{note} Additionally, the member function \tcode{allocate}
 for that type may fail by throwing an object of type
-\tcode{std::bad_alloc}.\end{note}
+\tcode{bad_alloc}.\end{note}
 
 \rSec4[allocator.requirements.completeness]{Allocator completeness requirements}