@@ -1,3 +1,29 @@
+2013-07-23 OndÅej BÃlka <neleai@seznam.cz>
+
+ * doc/doxygen/doxygroups.cc: Fix typos in libstdc++-v3.
+ * doc/html/ext/lwg-active.html: Likewise.
+ * doc/html/ext/lwg-closed.html: Likewise.
+ * doc/html/ext/lwg-defects.html: Likewise.
+ * doc/html/manual/appendix_contributing.html: Likewise.
+ * doc/html/manual/appendix_gfdl.html: Likewise.
+ * doc/html/manual/appendix_porting.html: Likewise.
+ * doc/html/manual/bitmap_allocator.html: Likewise.
+ * doc/html/manual/configure.html: Likewise.
+ * doc/html/manual/memory.html: Likewise.
+ * doc/html/manual/policy_data_structures.html: Likewise.
+ * doc/html/manual/strings.html: Likewise.
+ * include/bits/atomic_base.h: Likewise.
+ * include/bits/regex.h: Likewise.
+ * include/bits/valarray_array.h: Likewise.
+ * include/ext/cast.h: Likewise.
+ * include/ext/concurrence.h: Likewise.
+ * include/ext/mt_allocator.h: Likewise.
+ * testsuite/ext/pb_ds/example/hash_illegal_resize.cc: Likewise.
+ * testsuite/ext/pb_ds/example/tree_intervals.cc: Likewise.
+ * testsuite/util/exception/safety.h: Likewise.
+ * testsuite/util/testsuite_hooks.cc: Likewise.
+ * testsuite/util/testsuite_hooks.h: Likewise.
+
2013-07-22 Jason Merrill <jason@redhat.com>
PR libstdc++/57914
@@ -125,7 +125,7 @@ All sequences must meet certain requirements, summarized in
* @ingroup containers
Associative containers allow fast retrieval of data based on keys.
-Each container type is parameterized on a @c Key type, and an ordering
+Each container type is parametrized on a @c Key type, and an ordering
relation used to sort the elements of the container.
All associative containers must meet certain requirements, summarized in
@@ -136,7 +136,7 @@ All associative containers must meet certain requirements, summarized in
* @ingroup containers
Unordered associative containers allow fast retrieval of data based on keys.
-Each container type is parameterized on a @c Key type, a @c Hash type
+Each container type is parametrized on a @c Key type, a @c Hash type
providing a hashing functor, and an ordering relation used to sort the
elements of the container.
@@ -2351,7 +2351,7 @@ unordered containers do in 23.2.5 [unord.req]/3]</i>
</p>
<blockquote>
-2 Each associative container is parameterized on <tt>Key</tt> and an ordering
+2 Each associative container is parametrized on <tt>Key</tt> and an ordering
relation <tt>Compare</tt> that induces a strict weak ordering (25.4) on elements
of <tt>Key</tt>. In addition, <tt>map</tt> and <tt>multimap</tt> associate an
arbitrary <ins><em>mapped type</em></ins><del>type</del> <tt>T</tt> with the
@@ -2392,7 +2392,7 @@ which is important, because both can potentially be stateful.]</i>
<blockquote>
<p>
-3 Each unordered associative container is parameterized by <tt>Key</tt>, by a
+3 Each unordered associative container is parametrized by <tt>Key</tt>, by a
function object type <tt>Hash</tt> that meets the <tt>Hash</tt> requirements
(20.2.4) and acts as a hash function for argument values of type <tt>Key</tt>,
and by a binary predicate <tt>Pred</tt> that induces an equivalence relation on
@@ -2875,7 +2875,7 @@ for <tt>==</tt> and <tt>!=</tt>, but Howard convinced me not to do so (now).
</p>
<p><i>[
-2010-11-03 Daniel comments and adjustes the currently proposed wording changes:
+2010-11-03 Daniel comments and adjusts the currently proposed wording changes:
]</i></p>
@@ -5130,7 +5130,7 @@ comparisons into <tt><=.</tt>
<p><b>Proposed resolution:</b></p>
<p>
-Ammend [list.capacity] p1:
+Amend [list.capacity] p1:
</p>
<blockquote>
<p><tt>void resize(size_type sz);</tt></p>
@@ -5922,12 +5922,12 @@ Resolution proposed in ballot comment:
<blockquote>
-Initialisation of atomics:
+Initialization of atomics:
<p>
We believe the intent is that for any atomics there is a distinguished
-initialisation write, but that this need not happens-before all the
+initialization write, but that this need not happens-before all the
other operations on that atomic - specifically so that the
-initialisation write might be non-atomic and hence give rise to a data
+initialization write might be non-atomic and hence give rise to a data
race, and hence undefined behaviour, in examples such as this (from
Hans):
</p><blockquote><pre>atomic<atomic<int> *> p
@@ -7566,7 +7566,7 @@ requirement. A similar problem exists for <tt>is_placeholder</tt>.
]</i></p>
<p>
-Alisdair recognises this is clearly a bug introduced by some wording he
+Alisdair recognizes this is clearly a bug introduced by some wording he
wrote, the sole purpose of this metafunction is as a customization point
for users to write their own <tt>bind</tt>-expression types that participate
in the standard library <tt>bind</tt> protocol. The consensus was that this
@@ -8348,7 +8348,7 @@ None of these lists is meant to be exhaustive.
that doesn't quite fit any of the named paragraph categories
(e.g. <b>Effects</b>). Either we need a new kind of named
paragraph, or we need to put more material in unnamed paragraphs
- jsut after the signature. We need to talk to the Project Editor
+ just after the signature. We need to talk to the Project Editor
about how to do this.
]</i></p>
@@ -9081,7 +9081,7 @@ This issue refers to a requirements table we have removed.
</p>
<p>
The issue might now relate to 24.2.7 [random.access.iterators] p5.
-However, the rationale in the issue already recognises that the
+However, the rationale in the issue already recognizes that the
<tt>difference_type</tt> must be signed, so this really looks NAD.
</p>
</blockquote>
@@ -10853,7 +10853,7 @@ will hold the corresponding condition, or not."
a) "Places" has no special meaning, and the everyday language meaning
should fit.
b) The corresponding conditions were negated compared to the current
-wording, becaue the new wording requires it.
+wording, because the new wording requires it.
c) The wording "of the original range" might be redundant, since any
subrange starting at 'first' and containing no more elements than the
original range is implicitly a subrange of the original range [first,
@@ -11058,7 +11058,7 @@ by Thomas Mang regarding invalid iterator arithmetic expressions will
take this into account.
d) The wording "(for the version of unique without a predicate
argument)" and "(for the version of unique with a predicate argument)"
-was added consciously for clarity and is in resemblence with current
+was added consciously for clarity and is in resemblance with current
23.2.2.4 [lib.list.ops], paragraph 19. It might be considered redundant.
e) The wording "of the original range" might be redundant, since any
subrange starting at first and containing no more elements than the
@@ -11529,7 +11529,7 @@ clause 25.
In that case, 25 [lib.algorithms] paragraph 9 will certainly become
obsolete.
Alternatively,
-b) Add an appropiate paragraph similar to resolved 25 [lib.algorithms],
+b) Add an appropriate paragraph similar to resolved 25 [lib.algorithms],
paragraph 9, to the beginning of each clause containing invalid iterator
arithmetic expressions.
Alternatively,
@@ -11644,7 +11644,7 @@ not guarantee the substitution property or referential transparency).</p>
<p><b>View all other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#NAD">NAD</a> status.</p>
<p><b>Discussion:</b></p>
-<p>According to [lib.associative.reqmts] table 69, the runtime comlexity
+<p>According to [lib.associative.reqmts] table 69, the runtime complexity
of insert(p, t) and erase(q) can be done in amortized constant time.</p>
<p>It was my understanding that an associative container could be
@@ -12857,7 +12857,7 @@ l.remove(*l.begin());
</p>
<p>
Will delete the first element, and then continue trying to access it.
-This is particularily vicious, as it will appear to work in almost all
+This is particularly vicious, as it will appear to work in almost all
cases.
</p>
@@ -16974,7 +16974,7 @@ specific documents add their rules to this issue until the list is complete.
<p><i>[
-Bellevue: Wording is aleady present in various standards, and no-one has come forward with wording.
+Bellevue: Wording is already present in various standards, and no-one has come forward with wording.
Suggest a formal paper rather than a defect report is the correct way to proceed.
]</i></p>
@@ -17201,7 +17201,7 @@ Consider the following example:
// ...
</pre>
<p>
-Last but not least, the current behvaior is not only confusing to the casual
+Last but not least, the current behavior is not only confusing to the casual
reader, but it has also been confusing to some book authors. Besides
Stroustrup's book, other books (e.g. "Standard C++ IOStreams and Locales" by
Langer and Kreft) are describing the same mistaken assumption. Although books
@@ -24878,7 +24878,7 @@ concepts.
requirements of a random access iterator (24.1.5) such that
<code>iterator_traits<RandomAccessIterator>::value_type</code>
shall denote an <del>unsigned integral type</del><ins>unsigned integer
- type</ins> capable of accomodating 32-bit quantities.
+ type</ins> capable of accommodating 32-bit quantities.
</blockquote>
<p>
@@ -25858,7 +25858,7 @@ afternoon after a busy week...
</p>
<p>
-So as the decision was made on a wrong asumption, I propose to re-open
+So as the decision was made on a wrong assumption, I propose to re-open
the issue.
</p>
</blockquote>
@@ -26892,8 +26892,8 @@ Recommend NAD, addressed by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs
<p>
<tt>numeric_limits</tt> has functions specifically designed to return NaNs, which
break the model of <tt>Regular</tt> (via its axioms.) While floating point types
-will be acceptible in many algorithms taking <tt>Regular</tt> values, it is not
-appopriate for this specific API and we need a less refined constraint.
+will be acceptable in many algorithms taking <tt>Regular</tt> values, it is not
+appropriate for this specific API and we need a less refined constraint.
</p>
<p>FR 32:</p>
@@ -36179,7 +36179,7 @@ indicated:</i></p>
<p>
Object state is using a definition of object (instance of a class) from
-outside the standard, rather than the 'region of storage' definiton in
+outside the standard, rather than the 'region of storage' definition in
1.8 [intro.object]p1
</p>
@@ -38558,7 +38558,7 @@ concept_map Range<const XYZCorpContainer<T>> {
<blockquote>
<p>
-I recommend NAD, although remain concerned about header organisation.
+I recommend NAD, although remain concerned about header organization.
</p>
<p>
A user container will satisfy the <tt>MemberContainer</tt> concept, which IS auto.
@@ -40905,7 +40905,7 @@ In X [rand.concept.urng], we have the following:
<p>
Since the parameter <tt>G</tt> is in scope throughout the concept, there is no
-need for the axiom to be further parameterized, and so the axiom can be
+need for the axiom to be further parametrized, and so the axiom can be
slightly simplified as:
</p>
@@ -45265,7 +45265,7 @@ you sort it out.
Most reserved identifiers are treated as unilaterally available to the
implementation, such as to implement language extensions, or provide
macros documenting its functionality. However, the requirements for
-reserved identifers are in 17.6.3.3 [reserved.names], which are a
+reserved identifiers are in 17.6.3.3 [reserved.names], which are a
subsection of 17.6.3 [constraints]. 17.6.3.1 [constraints.overview] appears only to apply to "C++ programs
that use the facilities of the C++ standard library", meaning that, in
theory, all implementations are erroneous in having any non-standard
@@ -45333,7 +45333,7 @@ updated paper, and hopefully tracked via the LWG issues list instead.
It seems there are several classes of problems here and finding wording
to solve all in one paragraph could be too much. I suspect we need
several overlapping requirements that should cover the desired range of
-behaviours.
+behaviors.
</p>
<p>
@@ -46733,7 +46733,7 @@ to the FCD
<p>
This issue was discussed in Pittsburgh, and the decision there was to accept the
-typedef as proposed and move to Review. Unfortunately the issue was accidently
+typedef as proposed and move to Review. Unfortunately the issue was accidentally
applied to the FCD, and incorrectly. The FCD version of the typedef refers to
<tt>ratio<N, D></tt>, but the typedef is intended to refer to
<tt>ratio<num, den></tt> which in general is not the same type.
@@ -49064,7 +49064,7 @@ core feature Move Special Member Functions (N3044).
<hr>
-<h3><a name="1350"></a>1350. [FCD] Implicit contructors accidentally made some library types move-only</h3>
+<h3><a name="1350"></a>1350. [FCD] Implicit constructors accidentally made some library types move-only</h3>
<p><b>Section:</b> 17 [library] <b>Status:</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#Dup">Dup</a>
<b>Submitter:</b> Switzerland <b>Opened:</b> 2010-08-25 <b>Last modified:</b> 2010-10-25</p>
<p><b>View other</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-index-open.html#library">active issues</a> in [library].</p>
@@ -50206,7 +50206,7 @@ Depends on result of the review of WG14 work,
which is expected to be out to ballot during the
time wg21 is resolving its own ballot comments.
Liaison may also want to file comments in WG14
-to ensure compatibity from both sides.
+to ensure compatibility from both sides.
</p>
@@ -10869,7 +10869,7 @@ suggests so the LWG can decide between the two options.]</i></p>
defect fixing. We're now more sympathetic to it, but we (especially
Bill) are still worried about performance. N1780 describes a naive
algorithm, but it's not clear whether there is a non-naive
- implementation. Is it possible to implement this as efficently as
+ implementation. Is it possible to implement this as efficiently as
the current version of insert?]</i></p>
@@ -11969,7 +11969,7 @@ something like <tt>throw std::out_of_range("foo")</tt>, the const
string& constructor is invoked before anything gets thrown. The
copy constructor is potentially invoked during stack unwinding.</p>
-<p>The copy constructor is a more serious problem, becuase failure
+<p>The copy constructor is a more serious problem, because failure
during stack unwinding invokes <tt>terminate</tt>. The copy
constructor must be nothrow. <i>Curaçao: Howard thinks this
requirement may already be present.</i></p>
@@ -13536,7 +13536,7 @@ the wording. Dave provided new wording.]</i></p>
"singular".</p>
<p>Why do we say "may be singular", instead of "is singular"? That's
- becuase a valid iterator is one that is known to be nonsingular.
+ because a valid iterator is one that is known to be nonsingular.
Invalidating an iterator means changing it in such a way that it's
no longer known to be nonsingular. An example: inserting an
element into the middle of a vector is correctly said to invalidate
@@ -16261,7 +16261,7 @@ code example. That code example is however quite
inefficient because it requires several useless copies
of both the passed key_type value and of default
constructed mapped_type instances.
-My opinion is that was not meant by the comitee to
+My opinion is that was not meant by the committee to
require all those temporary copies.
</p>
@@ -16378,7 +16378,7 @@ we are no longer defining <tt>operator[]</tt> in terms of
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-Table 37, in 21.2.1 [char.traits.require], descibes char_traits::assign
+Table 37, in 21.2.1 [char.traits.require], describes char_traits::assign
as:
</p>
<pre> X::assign(c,d) assigns c = d.
@@ -16930,7 +16930,7 @@ shown in Table 51:
<p>The LWG considered, and rejected, an alternate proposal (described
as "Option 2" in the discussion). The main reason for rejecting it
- was that library implementors were concerened about implementation
+ was that library implementors were concerned about implementation
difficult, given that getting a C++ library to work smoothly with a
separately written C library is already a delicate business. Some
library implementers were also concerned about the issue of adding
@@ -17451,7 +17451,7 @@ prevents locale from being implemented efficiently.
<p><b>Rationale:</b></p>
-<p>This change is reasonable becuase it clarifies the intent of this
+<p>This change is reasonable because it clarifies the intent of this
part of the standard.</p>
@@ -17837,7 +17837,7 @@ function.
<p>
Although clause 23.1.2/8 guarantees that i remains a valid iterator
-througout this loop, absence of the stability requirement could
+throughout this loop, absence of the stability requirement could
potentially result in elements being skipped. This would make
this code incorrect, and, furthermore, means that there is no way
of erasing these elements without iterating first over the entire
@@ -18603,7 +18603,7 @@ impact on allowable optimizations.</p>
<p><b>Discussion:</b></p>
<p>
The specifications of toupper and tolower both specify the functions as
-const, althought they are not member functions, and are not specified as
+const, although they are not member functions, and are not specified as
const in the header file synopsis in section 22.3 [locales].
</p>
@@ -23500,7 +23500,7 @@ list<double> > should not take O(1).</p>
<p><i>[
-Post Oxford: We got <tt>swap</tt> for <tt>pair</tt> but accidently
+Post Oxford: We got <tt>swap</tt> for <tt>pair</tt> but accidentally
missed <tt>tuple</tt>. <tt>tuple::swap</tt> is being tracked by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#522">522</a>.
]</i></p>
@@ -28421,7 +28421,7 @@ In Berlin, WG14 decided to drop the <decfloat.h> header. The contents of
<del>The standard C++ headers <code><cfloat></code> and <code><float.h></code> define characteristics of the floating-point types <code>float</code>, <code>double</code>, and <code>long double</code>. Their contents remain unchanged by this Technical Report.</del>
</p>
<p>
-<del>Headers <code><cdecfloat></code> and <code><decfloat.h></code> define characteristics of the decimal floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>. As well, <code><decfloat.h></code> defines the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code>, for compatibilty with the C programming language.</del>
+<del>Headers <code><cdecfloat></code> and <code><decfloat.h></code> define characteristics of the decimal floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>. As well, <code><decfloat.h></code> defines the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code>, for compatibility with the C programming language.</del>
</p>
<p>
<ins>The header <code><cfloat></code> is described in [tr.c99.cfloat]. The header <code><float.h></code> is described in [tr.c99.floath]. These headers are extended by this Technical Report to define characteristics of the decimal floating-point types <code>decimal32</code>, <code>decimal64</code>, and <code>decimal128</code>. As well, <code><float.h></code> is extended to define the convenience typedefs <code>_Decimal32</code>, <code>_Decimal64</code>, and <code>_Decimal128</code> for compatibility with the C programming language.</ins>
@@ -29719,7 +29719,7 @@ Change 28.8.2 [re.regex.construct]:
<p>
is there an issue opened for (0,3) as complex number with
the French local? With the English local, the above parses as an
-imaginery complex number. With the French locale it parses as a
+imaginary complex number. With the French locale it parses as a
real complex number.
</p>
@@ -31619,7 +31619,7 @@ for all of these changes.
Even though <tt>unique_ptr<void></tt> is not a valid use case (unlike for <tt>shared_ptr<void></tt>),
unexpected cases to crop up which require the instantiation of the interface of <tt>unique_ptr<void></tt>
even if it is never used. For example see
-<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">LWG 541</a> for how this accidently
+<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#541">LWG 541</a> for how this accidentally
happened to <tt>auto_ptr</tt>. I believe the most robust way to protect <tt>unique_ptr</tt> against this
type of failure is to augment the return type of <tt>unique_ptr<T>:operator*()</tt> with
<tt>add_lvalue_reference<T>::type</tt>. This means that given an instantiated <tt>unique_ptr<void></tt>
@@ -32127,7 +32127,7 @@ post Bellevue Howard adds:
<blockquote>
<p>
-This issue was voted to WP in Bellevue, but accidently got stepped on by
+This issue was voted to WP in Bellevue, but accidentally got stepped on by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2525.pdf">N2525</a>
which was voted to WP simulataneously. Moving back to Open for the purpose of getting
the wording right. The intent of this issue and N2525 are not in conflict.
@@ -34055,7 +34055,7 @@ as well as the current draft
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2284.pdf">N2284</a>
(section 19.5 [syserr], p.2) proposes a
new
-enumeration type <tt>posix_errno</tt> immediatly in the namespace <tt>std</tt>. One of
+enumeration type <tt>posix_errno</tt> immediately in the namespace <tt>std</tt>. One of
the enumerators has the name <tt>invalid_argument</tt>, or fully qualified:
<tt>std::invalid_argument</tt>. This name clashes with the exception type
<tt>std::invalid_argument</tt>, see 19.2 [std.exceptions]/p.3. This clash makes
@@ -36459,7 +36459,7 @@ I wonder how the constructor <tt>bitset<N>::bitset(unsigned long)</tt> can
be declared as a <tt>constexpr</tt>. Current implementations usually have no such <tt>bitset</tt>
c'tor which would fulfill the requirements of a <tt>constexpr</tt> c'tor because they have a
non-empty c'tor body that typically contains for-loops or <tt>memcpy</tt> to compute the
-initialisation. What have I overlooked here?
+initialization. What have I overlooked here?
</li>
</ol>
@@ -36733,7 +36733,7 @@ column is valid, but not clear what semantics we need.
A table where there is no post-condition seems odd, but appears to sum up our position best.
</p>
<p>
-At a minimum an object is declared and is destuctible.
+At a minimum an object is declared and is destructible.
</p>
<p>
Move to open, as no-one happy to produce wording on the fly.
@@ -37397,7 +37397,7 @@ e, fmt, flags)</tt>, and then returns <tt>result</tt>.
<p><b>Discussion:</b></p>
<p>
The <tt>mersenne_twister_engine</tt> is required to use a seeding method that is given
-as an algorithm parameterized over the number of bits <tt>W</tt>. I doubt whether the given generalization
+as an algorithm parametrized over the number of bits <tt>W</tt>. I doubt whether the given generalization
of an algorithm that was originally developed only for unsigned 32-bit integers is appropriate
for other bit widths. For instance, <tt>W</tt> could be theoretically 16 and <tt>UIntType</tt> a 16-bit integer, in
which case the given multiplier would not fit into the <tt>UIntType</tt>. Moreover, T. Nishimura and M.
@@ -38351,7 +38351,7 @@ possibly more concise too.
<p><b>Proposed resolution:</b></p>
<p>
-Add new defintions to 17.3 [definitions]:
+Add new definitions to 17.3 [definitions]:
</p>
<blockquote>
@@ -38912,7 +38912,7 @@ The <tt>unique_ptr</tt> provides a semantics of strict ownership. A
<tt>MoveAssignable</tt>. <ins>The template parameter <tt>T</tt> of
<tt>unique_ptr</tt> may be an incomplete type.</ins> [ <i>Note:</i> The
uses of <tt>unique_ptr</tt> include providing exception safety for
-dynamically allcoated memory, passing ownership of dynamically allocated
+dynamically allocated memory, passing ownership of dynamically allocated
memory to a function, and returning dynamically allocated memory from a
function. -- <i>end note</i> ]
</blockquote>
@@ -41464,7 +41464,7 @@ requirements (Table 33), and the the <tt>MoveAssignable</tt> requirements (Table
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#CD1">CD1</a> status.</p>
<p><b>Discussion:</b></p>
<p>
-A comparision of the N2461 header <tt><complex></tt> synopsis ([complex.syn])
+A comparison of the N2461 header <tt><complex></tt> synopsis ([complex.syn])
with the C99 standard (ISO 9899, 2nd edition and the two corrigenda) show
some complex functions that are missing in C++. These are:
</p>
@@ -44302,7 +44302,7 @@ a place to see the complete solution in one place.
<tt>bind</tt> needs to be "moved".
</li>
<li>
-20.8.10.1.2 [func.bind.bind]/p3, p6 and p7 were accidently removed from N2798.
+20.8.10.1.2 [func.bind.bind]/p3, p6 and p7 were accidentally removed from N2798.
</li>
<li>
Issue <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#929">929</a> argues for a way to pass by && for
@@ -49908,7 +49908,7 @@ comparators, as described in 23.2.4 [associative.reqmts]/2:
</p>
<blockquote>
-Each associative container is parameterized on <tt>Key</tt> and an ordering
+Each associative container is parametrized on <tt>Key</tt> and an ordering
relation <tt>Compare</tt> that
induces a strict weak ordering (25.3) on elements of Key. [..]. The
object of type <tt>Compare</tt> is
@@ -49927,7 +49927,7 @@ equality predicate, see
<blockquote>
<p>
-Each unordered associative container is parameterized by <tt>Key</tt>, by a
+Each unordered associative container is parametrized by <tt>Key</tt>, by a
function object <tt>Hash</tt> that
acts as a hash function for values of type <tt>Key</tt>, and by a binary
predicate <tt>Pred</tt> that induces an
@@ -50063,7 +50063,7 @@ conversion function to e.g. pointer to function from being used in algorithms.
Now this last term "function objects" itself brings us to a third unsatisfactory
state: The term is used both for objects (e.g. "Function objects are
objects[..]" in 20.8 [function.objects]/1) and for types (e.g. "Each
-unordered associative container is parameterized [..] by a function object Hash
+unordered associative container is parametrized [..] by a function object Hash
that acts as a hash function [..]" in 23.2.5 [unord.req]/3). This
impreciseness should be fixed and I suggest to introduce the term <em>function
object type</em> as the counter part to <em>callable type</em>. This word seems
@@ -50289,7 +50289,7 @@ because the explicit naming of "pointer to function" is misleading]</i>
</p>
<blockquote>
-2 Each associative container is parameterized on <tt>Key</tt> and an ordering
+2 Each associative container is parametrized on <tt>Key</tt> and an ordering
relation <tt>Compare</tt> that induces a strict weak ordering (25.4 [alg.sorting]) on elements of <tt>Key</tt>. In addition, <tt>map</tt>
and <tt>multimap</tt> associate an arbitrary type <tt>T</tt> with the
<tt>Key</tt>. The object of type <tt>Compare</tt> is called the comparison
@@ -50304,7 +50304,7 @@ Change 23.2.5 [unord.req]/3 as indicated:
</p>
<blockquote>
-3 Each unordered associative container is parameterized by <tt>Key</tt>, by a
+3 Each unordered associative container is parametrized by <tt>Key</tt>, by a
function object <ins>type</ins> <tt>Hash</tt> that acts as a hash function for
values of type <tt>Key</tt>, and by a binary predicate <tt>Pred</tt> that
induces an equivalence relation on values of type Key. [..]
@@ -51214,7 +51214,7 @@ Recommend <del>NAD Editorial</del><ins>Resolved</ins>, fixed by
<p><b>View all issues with</b> <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-status.html#WP">WP</a> status.</p>
<p><b>Discussion:</b></p>
<blockquote><pre>20.2.3 pairs
-Missing assignemnt operator:
+Missing assignment operator:
template<class U , class V>
requires CopyAssignable<T1, U> && CopyAssignable<T2, V>
pair& operator=(pair<U , V> const & p );
@@ -54305,7 +54305,7 @@ Wording supplied by Daniel.
<p>
20.9.9.2.1 [unique.ptr.single.ctor]/5 no longer requires for <tt>D</tt>
-not to be a pointer type. I believe this restriction was accidently removed
+not to be a pointer type. I believe this restriction was accidentally removed
when we relaxed the completeness reuqirements on <tt>T</tt>. The restriction
needs to be put back in. Otherwise we have a run time failure that could
have been caught at compile time:
@@ -59438,7 +59438,7 @@ struct integral_constant {
<p>
The <tt>nullptr_t</tt> type was introduced to resolve the null pointer literal
-problem. It should be used for the assignemnt operator, as with the
+problem. It should be used for the assignment operator, as with the
constructor and elsewhere through the library.
</p>
@@ -59717,7 +59717,7 @@ represented by <tt>*this</tt> has completed.</ins> <tt>get_id() == id()</tt>.
<p>
It is not clear what purpose the Requirement tables serve in the
Containers clause. Are they the definition of a library Container? Or
-simply a conventient shorthand to factor common semantics into a single
+simply a convenient shorthand to factor common semantics into a single
place, simplifying the description of each subsequent container? This
becomes an issue for 'containers' like <tt>array</tt>, which does not meet the
default-construct-to-empty requirement, or <tt>forward_list</tt> which does not
@@ -60523,7 +60523,7 @@ void f(T&& x)
</pre></blockquote>
<p>
-Attempting to engineer <tt>forward</tt> to accomodate uses other than perfect
+Attempting to engineer <tt>forward</tt> to accommodate uses other than perfect
forwarding dilutes its idiomatic meaning. The solution proposed here
declares that <tt>forward<T>(x)</tt> means nothing more than <tt>static_cast<T&&>(x)</tt>,
with a patchwork of restrictions on what <tt>T</tt> and <tt>x</tt> can be that can't be
@@ -60539,7 +60539,7 @@ can't guarantee) I got right.
<li>
<p>
Use a simple definition of <tt>forward</tt> that accomplishes its original
-purpose without complications to accomodate other uses:
+purpose without complications to accommodate other uses:
</p>
<blockquote><pre>template <class T, class U>
@@ -61481,7 +61481,7 @@ Moved to Ready.
<blockquote>
<p>
Looking again at LWG #1079, the wording in the issue no longer exists, and
-appears to be entirely an artefact of the concepts wording.
+appears to be entirely an artifact of the concepts wording.
</p>
<p>
@@ -63388,7 +63388,7 @@ clear of that class while other constructor-related issues settle.
<p><b>Proposed resolution:</b></p>
<p>
-Ammend the tuple class template declaration in 20.4.2 [tuple.tuple] as
+Amend the tuple class template declaration in 20.4.2 [tuple.tuple] as
follows
</p>
@@ -63403,7 +63403,7 @@ Add the following concept:
</pre></blockquote>
<p>
-ammend the constructor
+amend the constructor
</p>
<blockquote><pre><ins>template <class... UTypes>
@@ -63418,7 +63418,7 @@ template <class... UTypes>
</pre></blockquote>
<p>
-ammend the constructor
+amend the constructor
</p>
<blockquote><pre><ins>template <class... UTypes>
@@ -63904,7 +63904,7 @@ Set to Tentatively Ready after 5 positive votes on c++std-lib.
<p><b>Proposed resolution:</b></p>
<p>
-Ammend in both:<br>
+Amend in both:<br>
24.6.3 [istreambuf.iterator]<br>
24.6.3.5 [istreambuf.iterator::equal]<br>
</p>
@@ -65407,7 +65407,7 @@ required to use a monotonic clock because such a clock may be unavailable.
<p><b>UK 327 Suggestion</b></p>
<p>Add a precondition <tt>!owns</tt>. Change the 'i.e.'
in the error condition to be 'e.g.' to allow for this
- condition to propogate deadlock detection by the host OS.</p>
+ condition to propagate deadlock detection by the host OS.</p>
<p><b>UK 327 Notes</b></p>
<p>Create an issue. Assigned to Lawrence Crowl. Note: not sure what try_lock
means for recursive locks when you are the owner. POSIX has language on
@@ -67853,7 +67853,7 @@ from, for example an <tt>int</tt>. Is this intended to compile?
<p>
Before the addition of this constructor, <tt>queue<int>(5)</tt> would not compile.
I ask, not because this crashes, but because it is new and appears to be
-unintended. We do not want to be in a position of accidently introducing this
+unintended. We do not want to be in a position of accidentally introducing this
"feature" in C++0X and later attempting to remove it.
</p>
@@ -68375,7 +68375,7 @@ Move to NAD.
It's not clear that there's any important difference between
"ill-formed" and "diagnostic required". From 1.4 [intro.compliance], 1.3.9 [defns.ill.formed], and 1.3.26 [defns.well.formed] it appears that an ill-formed program is one
that is not correctly constructed according to the syntax rules and
-diagnosable semantic rules, which means that... "a conforming
+diagnostible semantic rules, which means that... "a conforming
implementation shall issue at least one diagnostic message." The
author's intent seems to be that we should be requiring a fatal error
instead of a mere warning, but the standard just doesn't have language
@@ -69668,7 +69668,7 @@ Add to p1 25.4.5.1 [includes]:
<p>
The effects clause is invalid if the range <tt>[first,last)</tt> is empty, unlike
-all the other heap alogorithms. The should be called out in the
+all the other heap algorithms. The should be called out in the
requirements.
</p>
@@ -71408,7 +71408,7 @@ A lot of fixes were silently applied during concept-time and we should
not lose them again. The Requires clause of 25.3.9 [alg.unique]/5
doesn't mention that <tt>==</tt> and the predicate need to satisfy an
<tt>EquivalenceRelation</tt>, as it is correctly said for
-<tt>unique</tt>. This was intentionally fixed during conceptification,
+<tt>unique</tt>. This was intentionally fixed during conceptualization,
were we had:
</p>
@@ -71687,7 +71687,7 @@ the argument <tt>k</tt>. [<i>Note:</i> Thus all evaluations of the expression <t
<p><i>Change Unordered associative containers 23.2.5 [unord.req] as indicated:</i></p>
<blockquote>
- <p>Each unordered associative container is parameterized by <tt>Key</tt>, by a
+ <p>Each unordered associative container is parametrized by <tt>Key</tt>, by a
function object <ins>type</ins> <tt>Hash</tt><ins>([hash.requirements])</ins> that acts as a hash
function for <ins>argument</ins> values of type <tt>Key</tt>,
and by a binary predicate <tt>Pred</tt> that induces an equivalence relation
@@ -71775,7 +71775,7 @@ Add the term "exposition only" in the following two places:
</p>
<p>
-Ammend D.12.1 [auto.ptr]p2:
+Amend D.12.1 [auto.ptr]p2:
</p>
<blockquote>
@@ -72891,7 +72891,7 @@ supported.
<p><b>Proposed resolution:</b></p>
<p>
-Ammend p3 Freestanding implementations 17.6.1.3 [compliance]
+Amend p3 Freestanding implementations 17.6.1.3 [compliance]
</p>
<blockquote>
@@ -73277,7 +73277,7 @@ normal and exceptional circumstances.
<blockquote>
2 Some lock constructors take tag types which describe what should be
done with the <del>mutex</del><ins>lockable</ins> object during the
-lock's constuction.
+lock's construction.
</blockquote>
<p>30.4.2.1 [thread.lock.guard] paragaph 1:</p>
@@ -75949,7 +75949,7 @@ Post-Rapperswil:
<p>
Daniel notes: I changed the currently suggested P/R slightly, because it is not robust in regard to new fundamental iterator
-catagories. I recommend to say instead that each container::iterator shall satisfy (and thus may refine) the forward
+categories. I recommend to say instead that each container::iterator shall satisfy (and thus may refine) the forward
iterator requirements.
</p>
@@ -76778,7 +76778,7 @@ the initialization marked with # could be well-formed.
<p><i>[
Only constraints on constructors are suggested. Adding similar constraints on
-assignment operators is considered as QoI, because the assigments wouldn't be
+assignment operators is considered as QoI, because the assignments wouldn't be
well-formed anyway.
]</i></p>
@@ -79292,7 +79292,7 @@ Resolved in Rapperswil by a motion to directly apply the words from the ballot c
<p><b>Proposed resolution:</b></p>
With the exception of 18.8.2.1 [bad.exception],
-move clause 18.8.2 diectly to Annex D.
+move clause 18.8.2 directly to Annex D.
[bad.exception] should simply become the new
18.8.2.
@@ -79429,7 +79429,7 @@ Adopted at 2010-11 Batavia
<p>
The C++0x FCD recommends, in a note (see 19.5.1.1/1), that users
create a single <tt>error_category</tt> object for each user defined error
-category and specifies <tt>error_category</tt> equality comparsions based on
+category and specifies <tt>error_category</tt> equality comparisons based on
equality of addresses (19.5.1.3). The Draft apparently ignores this
when specifying standard error category objects in section 19.5.1.5,
by allowing the <tt>generic_category()</tt> and <tt>system_category()</tt>
@@ -80111,7 +80111,7 @@ Resolved by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/20
Several type traits require compiler support, e.g.
<tt>std::is_constructible</tt> or <tt>std::is_convertible</tt>.
Their current specification seems to imply, that the corresponding
-test expressions should be well-formed, even in absense of access:
+test expressions should be well-formed, even in absence of access:
</p>
<pre>class X { X(int){} };
constexpr bool test = std::is_constructible<X, int>::value;
@@ -80335,7 +80335,7 @@ Resolved by paper <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/20
<p><b>Discussion:</b></p>
<p><b>Addresses JP-3</b></p>
<p>
-<tt>explicit</tt> default contructor is defined in <tt>std::function</tt>.
+<tt>explicit</tt> default constructor is defined in <tt>std::function</tt>.
Although it is allowed according to 12.3.1, it seems
unnecessary to qualify the constructor as <tt>explicit</tt>.
If it is <tt>explicit</tt>, there will be a limitation in <tt>initializer_list</tt>.
@@ -82302,7 +82302,7 @@ Resolved in Batavia by accepting
The <tt>compare_exchange_weak</tt> and <tt>compare_exchange_strong</tt> member functions that take
<tt>const void*</tt> arguments lead to a silent removal of <tt>const</tt>, because the <tt>load</tt>
-member function and other acessors return the stored value as a <tt>void*</tt>.
+member function and other accesors return the stored value as a <tt>void*</tt>.
<p><i>[
Proposed resolution as of NB comment:
@@ -94,7 +94,7 @@
version of diff does not support these options, then get the
latest version of GNU
diff. The <a class="link" href="http://gcc.gnu.org/wiki/SvnTricks" target="_top">SVN
- Tricks</a> wiki page has information on customising the
+ Tricks</a> wiki page has information on customizing the
output of <code class="code">svn diff</code>.
</p></li><li class="listitem"><p>
When you have all these pieces, bundle them up in a
@@ -227,7 +227,7 @@
For any section Entitled âAcknowledgementsâ or
âDedicationsâ, Preserve the Title of the section, and
preserve in the section all the substance and tone of each of the
- contributor acknowledgements and/or dedications given therein.
+ contributor acknowledgments and/or dedications given therein.
</li><li class="listitem">
Preserve all the Invariant Sections of the Document, unaltered in
their text and in their titles. Section numbers or the equivalent are
@@ -90,13 +90,13 @@ in the build directory starts the build process. The <code class="literal">all</
</p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="build_hacking.configure.conventions"></a>Coding and Commenting Conventions</h4></div></div></div><p>
Most comments should use {octothorpes, shibboleths, hash marks,
pound signs, whatever} rather than "dnl". Nearly all comments in
- configure.ac should. Comments inside macros written in ancilliary
+ configure.ac should. Comments inside macros written in ancillary
.m4 files should. About the only comments which should
<span class="emphasis"><em>not</em></span> use #, but use dnl instead, are comments
- <span class="emphasis"><em>outside</em></span> our own macros in the ancilliary
+ <span class="emphasis"><em>outside</em></span> our own macros in the ancillary
files. The difference is that # comments show up in
<code class="code">configure</code> (which is most helpful for debugging),
- while dnl'd lines just vanish. Since the macros in ancilliary
+ while dnl'd lines just vanish. Since the macros in ancillary
files generate code which appears in odd places, their "outside"
comments tend to not be useful while reading
<code class="code">configure</code>.
@@ -280,7 +280,7 @@ in the build directory starts the build process. The <code class="literal">all</
make src
</p><p>
Generates two convenience libraries, one for C++98 and one for
- C++11, various compability files for shared and static
+ C++11, various compatibility files for shared and static
libraries, and then collects all the generated bits and creates
the final libstdc++ libraries.
</p><div class="orderedlist"><ol class="orderedlist" type="a"><li class="listitem"><p>
@@ -13,10 +13,10 @@
while 0 indicates allocated. This has been done so that you can
easily check a collection of bits for a free block. This kind of
Bitmapped strategy works best for single object allocations, and
- with the STL type parameterized allocators, we do not need to
+ with the STL type parametrized allocators, we do not need to
choose any size for the block which will be represented by a
single bit. This will be the size of the parameter around which
- the allocator has been parameterized. Thus, close to optimal
+ the allocator has been parametrized. Thus, close to optimal
performance will result. Hence, this should be used for node based
containers which call the allocate function with an argument of 1.
</p><p>
@@ -224,7 +224,7 @@
to standard error for certain events such as calling a pure virtual
function or the invocation of the standard terminate handler. Those
messages cause the library to depend on the demangler and standard I/O
- facilites, which might be undesirable in a low-memory environment or
+ facilities, which might be undesirable in a low-memory environment or
when standard error is not available. This option disables those
messages. This option does not change the library ABI.
</p></dd></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="setup.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="setup.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="make.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 2. Setup </td><td width="20%" align="center"><a accesskey="h" href="../index.html">Home</a></td><td width="40%" align="right" valign="top"> Make</td></tr></table></div></body></html>
\ No newline at end of file
@@ -453,7 +453,7 @@ pointer of type <span class="type">_Sp_counted_base*</span> which points to the
object that maintains the reference-counts and destroys the managed
resource.
</p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="classname">_Sp_counted_base<Lp></code></span></dt><dd><p>
-The base of the hierarchy is parameterized on the lock policy (see below.)
+The base of the hierarchy is parametrized on the lock policy (see below.)
_Sp_counted_base doesn't depend on the type of pointer being managed,
it only maintains the reference counts and calls virtual functions when
the counts drop to zero. The managed object is destroyed when the last
@@ -484,7 +484,7 @@ Contains aligned storage to hold an object of type <span class="type">Tp</span>,
which is constructed in-place with placement <code class="function">new</code>.
Has a variadic template constructor allowing any number of arguments to
be forwarded to <span class="type">Tp</span>'s constructor.
-Unlike the other <code class="classname">_Sp_counted_*</code> classes, this one is parameterized on the
+Unlike the other <code class="classname">_Sp_counted_*</code> classes, this one is parametrized on the
type of object, not the type of pointer; this is purely a convenience
that simplifies the implementation slightly.
</p></dd></dl></div><p>
@@ -540,9 +540,9 @@ Policy below for details.
</p></div><div class="section"><div class="titlepage"><div><div><h5 class="title"><a id="idm140623071342672"></a>Selecting Lock Policy</h5></div></div></div><p>
</p><p>
There is a single <code class="classname">_Sp_counted_base</code> class,
-which is a template parameterized on the enum
+which is a template parametrized on the enum
<span class="type">__gnu_cxx::_Lock_policy</span>. The entire family of classes is
-parameterized on the lock policy, right up to
+parametrized on the lock policy, right up to
<code class="classname">__shared_ptr</code>, <code class="classname">__weak_ptr</code> and
<code class="classname">__enable_shared_from_this</code>. The actual
<code class="classname">std::shared_ptr</code> class inherits from
@@ -86,7 +86,7 @@
the source files, but the generated names for external symbols can
be large for binary files or debuggers.
</p><p>
- In many cases, the longer names allow capabilities and behaviours
+ In many cases, the longer names allow capabilities and behaviors
controlled by macros to also be unamibiguously emitted as distinct
generated names.
</p><p>
@@ -127,7 +127,7 @@
very good information.
</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="strings.string.character_types"></a>Arbitrary Character Types</h3></div></div></div><p>
</p><p>The <code class="code">std::basic_string</code> is tantalizingly general, in that
- it is parameterized on the type of the characters which it holds.
+ it is parametrized on the type of the characters which it holds.
In theory, you could whip up a Unicode character class and instantiate
<code class="code">std::basic_string<my_unicode_char></code>, or assuming
that integers are wider than characters on your platform, maybe just
@@ -255,7 +255,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*
* Base type is POD with data, allowing atomic_flag to derive from
* it and meet the standard layout type requirement. In addition to
- * compatibilty with a C interface, this allows different
+ * compatibility with a C interface, this allows different
* implementations of atomic_flag to use the same atomic operation
* functions, via a standard conversion to the __atomic_flag_base
* argument.
@@ -43,7 +43,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* A regular expression traits class that satisfies the requirements of
* section [28.7].
*
- * The class %regex is parameterized around a set of related types and
+ * The class %regex is parametrized around a set of related types and
* functions used to complete the definition of its semantics. This class
* satisfies the requirements of such a traits class.
*/
@@ -336,7 +336,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
//
// Compute the sum of elements in range [__f, __l)
- // This is a naive algorithm. It suffers from cancelling.
+ // This is a naive algorithm. It suffers from canceling.
// In the future try to specialize
// for _Tp = float, double, long double using a more accurate
// algorithm.
@@ -38,7 +38,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* These functions are here to allow containers to support non standard
* pointer types. For normal pointers, these resolve to the use of the
* standard cast operation. For other types the functions will perform
- * the apprpriate cast to/from the custom pointer class so long as that
+ * the appropriate cast to/from the custom pointer class so long as that
* class meets the following conditions:
* 1) has a typedef element_type which names tehe type it points to.
* 2) has a get() const method which returns element_type*.
@@ -48,7 +48,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// _S_atomic multi-threaded code using atomic operations.
enum _Lock_policy { _S_single, _S_mutex, _S_atomic };
- // Compile time constant that indicates prefered locking policy in
+ // Compile time constant that indicates preferred locking policy in
// the current configuration.
static const _Lock_policy __default_lock_policy =
#ifdef __GTHREADS
@@ -185,7 +185,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
/**
- * @brief Data describing the underlying memory pool, parameterized on
+ * @brief Data describing the underlying memory pool, parametrized on
* threading support.
*/
template<bool _Thread>
@@ -38,7 +38,7 @@
/**
* This example shows the case where a hash-based container object is
- * resized to a value which it cannot accomodate at runtime. Illegal
+ * resized to a value which it cannot accommodate at runtime. Illegal
* runtime resizes cause an exception.
*/
@@ -64,7 +64,7 @@ using namespace __gnu_pbds;
// on them. As the purpose of this example is node invariants, and not
// computational-geometry algorithms per-se, some simplifications are
// made (e.g., intervals are defined by unsigned integers, and not by
-// a parameterized type, data members are public, etc.).
+// a parametrized type, data members are public, etc.).
// An interval of unsigned integers.
typedef pair< unsigned int, unsigned int> interval;
@@ -1208,7 +1208,7 @@ namespace __gnu_test
try
{
// An exception while assigning might leave the container empty
- // making future attemps less relevant. So we copy it before to
+ // making future attempts less relevant. So we copy it before to
// always assign to a non empty container. It also check for copy
// constructor exception safety at the same time.
_Tp __clone(__container);
@@ -237,7 +237,7 @@ namespace __gnu_test
semaphore::semaphore()
{
#ifdef _GLIBCXX_SYSV_SEM
- // Remeber the PID for the process that created the semaphore set
+ // Remember the PID for the process that created the semaphore set
// so that only one process will destroy the set.
pid_ = getpid();
@@ -228,7 +228,7 @@ namespace __gnu_test
};
// An class of objects that can be used for validating various
- // behaviours and guarantees of containers and algorithms defined in
+ // behaviors and guarantees of containers and algorithms defined in
// the standard library.
class copy_tracker
{