This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 4/5] Fix typos in libstdc++.
- From: Paolo Carlini <paolo dot carlini at oracle dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Tue, 23 Jul 2013 13:16:57 +0200
- Subject: Re: [PATCH 4/5] Fix typos in libstdc++.
- References: <20130723104529 dot GC6395 at domone dot kolej dot mff dot cuni dot cz>
Hi,
spotted a few debatable items.
On 07/23/2013 12:45 PM, OndÅej BÃlka wrote:
-Ammend D.12.1 [auto.ptr]p2:
+Amend D.12.1 [auto.ptr]p2:
^^
-Ammend [list.capacity] p1:
+Amend [list.capacity] p1:
^^
-Ammend in both:<br>
+Amend in both:<br>
^^
-Ammend p3 Freestanding implementations 17.6.1.3 [compliance]
+Amend p3 Freestanding implementations 17.6.1.3 [compliance]
^^
-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
^^
-Initialisation of atomics:
+Initialization of atomics:
^ ^
- // Remeber the PID for the process that created the semaphore set
+ // Remember the PID for the process that created the semaphore set
^ ^
ressions should be well-formed, even in absense of access:
ressions should be well-formed, even in absence of access:
^ ^
-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>.
^ ^
I think accessor is fine.
to Review. Unfortunately the issue was accidently
to Review. Unfortunately the issue was accidentally
^ ^
got <tt>swap</tt> for <tt>pair</tt> but accidently
got <tt>swap</tt> for <tt>pair</tt> but accidentally
^ ^
ects.html#541">LWG 541</a> for how this accidently
ects.html#541">LWG 541</a> for how this accidentally
^ ^
issue was voted to WP in Bellevue, but accidently got stepped on by
issue was voted to WP in Bellevue, but accidentally got stepped on by
^ ^
We do not want to be in a position of accidently introducing this
We do not want to be in a position of accidentally introducing this
^ ^
r type. I believe this restriction was accidently removed
r type. I believe this restriction was accidentally removed
^ ^
1.2 [func.bind.bind]/p3, p6 and p7 were accidently removed from N2798.
1.2 [func.bind.bind]/p3, p6 and p7 were accidentally removed from N2798.
^ ^
- * resized to a value which it cannot accomodate at runtime. Illegal
+ * resized to a value which it cannot accommodate at runtime. Illegal
^ ^
-purpose without complications to accomodate other uses:
+purpose without complications to accommodate other uses:
^ ^
empting to engineer <tt>forward</tt> to accomodate uses other than perfect
empting to engineer <tt>forward</tt> to accommodate uses other than perfect
^ ^
- type</ins> capable of accomodating 32-bit quantities.
+ type</ins> capable of accommodating 32-bit quantities.
^ ^
- contributor acknowledgements and/or dedications given therein.
+ contributor acknowledgments and/or dedications given therein.
^ ^
-2010-11-03 Daniel comments and adjustes the currently proposed wording changes:
+2010-11-03 Daniel comments and adjusts the currently proposed wording changes:
^ ^
-all the other heap alogorithms. The should be called out in the
+all the other heap algorithms. The should be called out in the
^^
-dynamically allcoated memory, passing ownership of dynamically allocated
+dynamically allocated memory, passing ownership of dynamically allocated
^ ^
-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.
^ ^
-const, althought they are not member functions, and are not specified as
+const, although they are not member functions, and are not specified as
^ ^
-ammend the constructor
+amend the constructor
^^
-ammend the constructor
+amend the constructor
^^
uld. Comments inside macros written in ancilliary
uld. Comments inside macros written in ancillary
^ ^
tside</em></span> our own macros in the ancilliary
tside</em></span> our own macros in the ancillary
^ ^
lines just vanish. Since the macros in ancilliary
lines just vanish. Since the macros in ancillary
^ ^
- * 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
^ ^
-b) Add an appropiate paragraph similar to resolved 25 [lib.algorithms],
+b) Add an appropriate paragraph similar to resolved 25 [lib.algorithms],
^ ^
-appears to be entirely an artefact of the concepts wording.
+appears to be entirely an artifact of the concepts wording.
^ ^
-problem. It should be used for the assignemnt operator, as with the
+problem. It should be used for the assignment operator, as with the
^ ^
-Missing assignemnt operator:
+Missing assignment operator:
^ ^
ators is considered as QoI, because the assigments wouldn't be
ators is considered as QoI, because the assignments wouldn't be
^ ^
-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
^^
- // making future attemps less relevant. So we copy it before to
+ // making future attempts less relevant. So we copy it before to
^ ^
- becuase a valid iterator is one that is known to be nonsingular.
+ because a valid iterator is one that is known to be nonsingular.
^ ^
constructor is a more serious problem, becuase failure
constructor is a more serious problem, because failure
^ ^
-<p>This change is reasonable becuase it clarifies the intent of this
+<p>This change is reasonable because it clarifies the intent of this
^ ^
-wording, becaue the new wording requires it.
+wording, because the new wording requires it.
^ ^
-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
^ ^
the longer names allow capabilities and behaviours
the longer names allow capabilities and behaviors
^ ^
- // behaviours and guarantees of containers and algorithms defined in
+ // behaviors and guarantees of containers and algorithms defined in
^ ^
-behaviours.
+behaviors.
^ ^
is a naive algorithm. It suffers from cancelling.
is a naive algorithm. It suffers from canceling.
^ ^
-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
^ ^
My opinion is that was not meant by the comitee to
My opinion is that was not meant by the committee to
^ ^
-A comparision of the N2461 header <tt><complex></tt> synopsis ([complex.syn])
+A comparison of the N2461 header <tt><complex></tt> synopsis ([complex.syn])
^ ^
cifies <tt>error_category</tt> equality comparsions based on
cifies <tt>error_category</tt> equality comparisons based on
^ ^
- C++11, various compability files for shared and static
+ C++11, various compatibility files for shared and static
^ ^
-to ensure compatibity from both sides.
+to ensure compatibility from both sides.
^ ^
- * compatibilty with a C interface, this allows different
+ * compatibility with a C interface, this allows different
^ ^
ode>, and <code>_Decimal128</code>, for compatibilty with the C programming language.</del>
ode>, and <code>_Decimal128</code>, for compatibility with the C programming language.</del>
^ ^
sociative.reqmts] table 69, the runtime comlexity
sociative.reqmts] table 69, the runtime complexity
^ ^
t>. This was intentionally fixed during conceptification,
t>. This was intentionally fixed during conceptualization,
^ ^
Hard core jargon ;) I think conceptification can stay.
- was that library implementors were concerened about implementation
+ was that library implementors were concerned about implementation
^ ^
-lock's constuction.
+lock's construction.
^ ^
-<tt>explicit</tt> default contructor is defined in <tt>std::function</tt>.
+<tt>explicit</tt> default constructor is defined in <tt>std::function</tt>.
^ ^
<a name="1350"></a>1350. [FCD] Implicit contructors accidentally made some library types move-only</h3>
<a name="1350"></a>1350. [FCD] Implicit constructors accidentally made some library types move-only</h3>
^ ^
-simply a conventient shorthand to factor common semantics into a single
+simply a convenient shorthand to factor common semantics into a single
^ ^
Tricks</a> wiki page has information on customising the
Tricks</a> wiki page has information on customizing the
^ ^
rd, rather than the 'region of storage' definiton in
rd, rather than the 'region of storage' definition in
^ ^
-Add new defintions to 17.3 [definitions]:
+Add new definitions to 17.3 [definitions]:
^ ^
le 37, in 21.2.1 [char.traits.require], descibes char_traits::assign
le 37, in 21.2.1 [char.traits.require], describes char_traits::assign
^ ^
a minimum an object is declared and is destuctible.
a minimum an object is declared and is destructible.
^ ^
-diagnosable semantic rules, which means that... "a conforming
+diagnostible semantic rules, which means that... "a conforming
^ ^
Not 100% sure, but diagnostible seems weird (the spelling checker of my
Thunderbird agrees ;)
-move clause 18.8.2 diectly to Annex D.
+move clause 18.8.2 directly to Annex D.
^ ^
on. Is it possible to implement this as efficently as
on. Is it possible to implement this as efficiently as
^ ^
- facilites, which might be undesirable in a low-memory environment or
+ facilities, which might be undesirable in a low-memory environment or
^ ^
-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
^ ^
-imaginery complex number. With the French locale it parses as a
+imaginary complex number. With the French locale it parses as a
^ ^
-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
^ ^
-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
^ ^
-initialisation write, but that this need not happens-before all the
+initialization write, but that this need not happens-before all the
^ ^
-initialisation. What have I overlooked here?
+initialization. What have I overlooked here?
^ ^
- jsut after the signature. We need to talk to the Project Editor
+ just after the signature. We need to talk to the Project Editor
^ ^
although remain concerned about header organisation.
although remain concerned about header organization.
^ ^
-unordered associative container is parameterized [..] by a function object Hash
+unordered associative container is parametrized [..] by a function object Hash
^ ^
- with the STL type parameterized allocators, we do not need to
+ with the STL type parametrized allocators, we do not need to
^ ^
- * The class %regex is parameterized around a set of related types and
+ * The class %regex is parametrized around a set of related types and
^ ^
Each unordered associative container is parameterized by <tt>Key</tt>, by a
Each unordered associative container is parametrized by <tt>Key</tt>, by a
^ ^
Each unordered associative container is parameterized by <tt>Key</tt>, by a
Each unordered associative container is parametrized by <tt>Key</tt>, by a
^ ^
Each unordered associative container is parameterized by <tt>Key</tt>, by a
Each unordered associative container is parametrized by <tt>Key</tt>, by a
^ ^
Each unordered associative container is parameterized by <tt>Key</tt>, by a
Each unordered associative container is parametrized by <tt>Key</tt>, by a
^ ^
describing the underlying memory pool, parameterized on
describing the underlying memory pool, parametrized on
^ ^
-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
^ ^
-Each associative container is parameterized on <tt>Key</tt> and an ordering
+Each associative container is parametrized on <tt>Key</tt> and an ordering
^ ^
-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
^ ^
-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
^ ^
-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
^ ^
p_counted_*</code> classes, this one is parameterized on the
p_counted_*</code> classes, this one is parametrized on the
^ ^
-which is a template parameterized on the enum
+which is a template parametrized on the enum
^ ^
-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.)
^ ^
-parameterized on the lock policy, right up to
+parametrized on the lock policy, right up to
^ ^
- it is parameterized on the type of the characters which it holds.
+ it is parametrized on the type of the characters which it holds.
^ ^
-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
^ ^
-// a parameterized type, data members are public, etc.).
+// a parametrized type, data members are public, etc.).
^ ^
-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
^ ^
- the allocator has been parameterized. Thus, close to optimal
+ the allocator has been parametrized. Thus, close to optimal
^ ^
Jargon again, I don't think we want parametrized.
Paolo.