typos in libstdc++ docs
Ralf Wildenhues
Ralf.Wildenhues@gmx.de
Sat Dec 16 16:08:00 GMT 2006
The patch below fixes some typos in libstdc++ docs.
Also, let me ping a patch for typos in gcc docs:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29972
Cheers,
Ralf
libstdc++-v3/ChangeLog:
2006-12-16 Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
* docs/html/27_io/howto.html: Fix typos.
* docs/html/24_iterators/howto.html: Likewise.
* docs/html/18_support/howto.html: Likewise.
* docs/html/21_strings/howto.html: Likewise.
* docs/html/ext/howto.html: Likewise.
* docs/html/ext/ballocator_doc.html: Likewise.
* docs/html/17_intro/porting-howto.xml: Likewise.
* docs/html/17_intro/howto.html: Likewise.
* docs/html/22_locale/howto.html: Likewise.
* docs/html/faq/index.html: Likewise.
* docs/doxygen/tables.html: Likewise.
Index: docs/html/27_io/howto.html
===================================================================
--- docs/html/27_io/howto.html (Revision 119961)
+++ docs/html/27_io/howto.html (Arbeitskopie)
@@ -102,13 +102,13 @@
blank lines and only "Thequickbrownfox...". With
libraries that do not define that operator, IN (or one of IN's
member pointers) sometimes gets converted to a void*, and the output
- file then contains a perfect text representation of a hexidecimal
+ file then contains a perfect text representation of a hexadecimal
address (quite a big surprise). Others don't compile at all.
</p>
<p>Also note that none of this is specific to o<b>*f*</b>streams.
The operators shown above are all defined in the parent
basic_ostream class and are therefore available with all possible
- descendents.
+ descendants.
</p>
<p>Return <a href="#top">to top of page</a> or
<a href="../faq/index.html">to the FAQ</a>.
@@ -569,7 +569,7 @@
be built and included in libstdc++.
</p>
<h3>Alternatives</h3>
- <p>Don't forget that other cstdio implemenations are possible. You could
+ <p>Don't forget that other cstdio implementations are possible. You could
easily write one to perform your own forms of locking, to solve your
"interesting" problems.
</p>
@@ -643,7 +643,7 @@
interfaces, then you only need to use the appropriate interface header.
</p>
<p><strong><iomanip></strong> provides "extractors and inserters
- that alter information maintained by class ios_base and its dervied
+ that alter information maintained by class ios_base and its derived
classes," such as std::setprecision and std::setw. If you need
to write expressions like <code>os << setw(3);</code> or
<code>is >> setbase(8);</code>, you must include <iomanip>.
Index: docs/html/24_iterators/howto.html
===================================================================
--- docs/html/24_iterators/howto.html (Revision 119961)
+++ docs/html/24_iterators/howto.html (Arbeitskopie)
@@ -67,7 +67,7 @@
things as it would be doing if you had hand-coded it yourself (for
the 273rd time).
</p>
- <p>How much overhead <em>is</em> there when using an interator class?
+ <p>How much overhead <em>is</em> there when using an iterator class?
Very little. Most of the layering classes contain nothing but
typedefs, and typedefs are "meta-information" that simply
tell the compiler some nicknames; they don't create code. That
Index: docs/html/18_support/howto.html
===================================================================
--- docs/html/18_support/howto.html (Revision 119961)
+++ docs/html/18_support/howto.html (Arbeitskopie)
@@ -125,7 +125,7 @@
<h3><code><limits></code></h3>
<p>This header mainly defines traits classes to give access to various
implementation defined-aspects of the fundamental types. The
- traits classes -- fourteen in total -- are all specilizations of the
+ traits classes -- fourteen in total -- are all specializations of the
template class <code>numeric_limits</code>, documented
<a href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/structstd_1_1numeric__limits.html">here</a>
and defined as follows:
Index: docs/html/21_strings/howto.html
===================================================================
--- docs/html/21_strings/howto.html (Revision 119961)
+++ docs/html/21_strings/howto.html (Arbeitskopie)
@@ -133,7 +133,7 @@
<li>Microsoft ships the source to CString (in the files
MFC\SRC\Str{core,ex}.cpp), so you could fix the allocation
bug and rebuild your MFC libraries.
- <em><strong>Note:</strong> It looks like the the CString shipped
+ <em><strong>Note:</strong> It looks like the CString shipped
with VC++6.0 has fixed this, although it may in fact have been
one of the VC++ SPs that did it.</em>
</li>
@@ -252,7 +252,7 @@
<code>ls.size()</code> will return how many tokens there were.
</p>
<p>As always, there is a price paid here, in that stringtok is not
- as fast as strtok. The other benefits usually outweight that, however.
+ as fast as strtok. The other benefits usually outweigh that, however.
<a href="stringtok_std_h.txt">Another version of stringtok is given
here</a>, suggested by Chris King and tweaked by Petr Prikryl,
and this one uses the
Index: docs/html/ext/howto.html
===================================================================
--- docs/html/ext/howto.html (Revision 119961)
+++ docs/html/ext/howto.html (Arbeitskopie)
@@ -387,7 +387,7 @@
<em>operator>>(istream&, string&) doesn't set failbit</em>
</dt>
<dd>If nothing is extracted into the string, <code>op>></code> now
- sets <code>failbit</code> (which can cause an exception, etc, etc).
+ sets <code>failbit</code> (which can cause an exception, etc., etc.).
</dd>
<dt><a href="lwg-defects.html#214">214</a>:
Index: docs/html/ext/ballocator_doc.html
===================================================================
--- docs/html/ext/ballocator_doc.html (Revision 119961)
+++ docs/html/ext/ballocator_doc.html (Arbeitskopie)
@@ -40,7 +40,7 @@
<hr style="width: 100%; height: 2px;"><br>
The macro __GTHREADS decides whether to use Mutex Protection around
every allocation/deallocation. The state of the macro is picked up
-automatically from the gthr abstration layer.<br>
+automatically from the gthr abstraction layer.<br>
<br>
<hr style="width: 100%; height: 2px;">
<h3 style="text-align: center;">What is the Free List Store?</h3>
@@ -125,11 +125,11 @@
Suppose n == 1, then the allocator does the following:<br>
<br>
<ol>
- <li>Checks to see whether the a free block exists somewhere in a
+ <li>Checks to see whether a free block exists somewhere in a
region of memory close to the last satisfied request. If so, then that
block is marked as allocated in the bit map and given to the user. If
not, then (2) is executed.</li>
- <li>Is there a free block anywhere after the current block right upto
+ <li>Is there a free block anywhere after the current block right up to
the end of the memory that we have? If so, that block is found, and the
same procedure is applied as above, and returned to the user. If not,
then (3) is executed.</li>
@@ -275,7 +275,7 @@
Another issue would be whether to keep the all bitmaps in a separate
area in memory, or to keep them near the actual blocks that will be
given out or allocated for the client. After some testing, I've decided
-to keep these bitmaps close to the actual blocks. this will help in 2
+to keep these bitmaps close to the actual blocks. This will help in 2
ways. <br>
<br>
<ol>
@@ -310,7 +310,7 @@
minimize them would be a good thing to do at the cost of a little bit
of memory.<br>
<br>
-Another thing to be noted is the the pool size will double every time
+Another thing to be noted is the pool size will double every time
the internal pool gets exhausted, and all the free blocks have been
given away. The initial size of the pool would be sizeof(size_t) x 8
which is the number of bits in an integer, which can fit exactly
@@ -348,7 +348,7 @@
single objects to be given, there will be '32 x (2^3)' bits present.
Each
32 bits managing the allocated / free status for 32 blocks. Since each
-size_t contains 32-bits, one size_t can manage upto 32
+size_t contains 32-bits, one size_t can manage up to 32
blocks' status. Each bit-map is made up of a number of size_t,
whose exact number for a super-block of a given size I have just
mentioned.<br>
@@ -364,19 +364,19 @@
32 bits at a time to check whether there is at lease one free block in
those 32 blocks by testing for equality with (0). Now, the allocate
function will given a memory block find the corresponding bit in the
-bitmap, and will reset it (ie. make it re-set (0)). And when the
+bitmap, and will reset it (i.e., make it re-set (0)). And when the
deallocate function is called, it will again set that bit after
locating it to indicate that that particular block corresponding to
this bit in the bit-map is not being used by anyone, and may be used to
satisfy future requests.<br>
<br>
-eg: Consider a bit-map of 64-bits as represented below:<br>
+e.g.: Consider a bit-map of 64-bits as represented below:<br>
1111111111111111111111111111111111111111111111111111111111111111<br>
<br>
Now, when the first request for allocation of a single object comes
along, the first block in address order is returned. And since the
bit-maps in the reverse order to that of the address order, the last
-bit(LSB if the bit-map is considered as a binary word of 64-bits) is
+bit (LSB if the bit-map is considered as a binary word of 64-bits) is
re-set to 0.<br>
<br>
The bit-map now looks like this:<br>
@@ -400,7 +400,7 @@
k => The constant overhead per node. eg. for list, it is 8 bytes,
and for map it is 12 bytes.<br>
c => The size of the base type on which the map/list is
-instantiated. Thus, suppose the the type1 is int and type2 is double,
+instantiated. Thus, suppose the type1 is int and type2 is double,
they are related by the relation sizeof(double) == 2*sizeof(int). Thus,
all types must have this double size relation for this formula to work
properly.<br>
Index: docs/html/17_intro/porting-howto.xml
===================================================================
--- docs/html/17_intro/porting-howto.xml (Revision 119961)
+++ docs/html/17_intro/porting-howto.xml (Arbeitskopie)
@@ -363,7 +363,7 @@
<paramdef>int <parameter>size</parameter></paramdef>
</funcprototype>
</funcsynopsis>
- but the the signature of this constructor has changed often, and
+ but the signature of this constructor has changed often, and
it might change again. For the current state of this, check
<ulink url="../ext/howto.html">the howto for extensions</ulink>.
</para>
Index: docs/html/17_intro/howto.html
===================================================================
--- docs/html/17_intro/howto.html (Revision 119961)
+++ docs/html/17_intro/howto.html (Arbeitskopie)
@@ -189,7 +189,7 @@
<p>We do so here, for the C++ library only. Behavior of the compiler,
linker, runtime loader, and other elements of "the
implementation" are documented elsewhere. Everything listed in
- Annex B, Implemenation Qualities, are also part of the compiler, not
+ Annex B, Implementation Qualities, are also part of the compiler, not
the library.
</p>
<p>For each entry, we give the section number of the standard, when
@@ -256,7 +256,7 @@
for what does exist.
</p>
<p><strong>[22.*]</strong> Anything and everything we have on locale
- implemenation will be described
+ implementation will be described
<a href="../22_locale/howto.html">over here</a>.
</p>
<p><strong>[26.2.8]/9</strong> I have no idea what
Index: docs/html/22_locale/howto.html
===================================================================
--- docs/html/22_locale/howto.html (Revision 119961)
+++ docs/html/22_locale/howto.html (Arbeitskopie)
@@ -137,7 +137,7 @@
Fine, you asked for it...)
</p>
<p>The task of changing the case of a letter or classifying a character
- as numeric, graphical, etc, all depends on the cultural context of the
+ as numeric, graphical, etc., all depends on the cultural context of the
program at runtime. So, first you must take the portability question
into account. Once you have localized the program to a particular
natural language, only then can you perform the specific task.
Index: docs/html/faq/index.html
===================================================================
--- docs/html/faq/index.html (Revision 119961)
+++ docs/html/faq/index.html (Arbeitskopie)
@@ -250,7 +250,7 @@
in the implementation, however handy they are. (The extensions
provided in the SGI STL aren't maintained by us and don't get
a lot of our attention, because they don't require a lot of our
- time.) It is entirely plausable that the "useful stuff"
+ time.) It is entirely plausible that the "useful stuff"
from libg++ might be extracted into an updated utilities library,
but nobody has started such a project yet.
</p>
@@ -504,7 +504,7 @@
<p>These macros are typically used in C library headers, guarding new
versions of functions from their older versions. The C++ standard
library includes the C standard library, but it requires the C90
- version, which for backwards-compatability reasons is often not the
+ version, which for backwards-compatibility reasons is often not the
default for many vendors.
</p>
<p>More to the point, the C++ standard requires behavior which is only
@@ -592,7 +592,7 @@
<hr />
<h1><a name="4_0">4.0 Known Bugs and Non-Bugs</a></h1>
- <em>Note that this section can get rapdily outdated -- such is the
+ <em>Note that this section can get rapidly outdated -- such is the
nature of an open-source project. For the latest information, join
the mailing list or look through recent archives. The RELEASE-
NOTES and BUGS files are generally kept up-to-date.</em>
@@ -1006,10 +1006,10 @@
</p>
<p><strong>Function objects - Complete -</strong>
- Function return types (i.e, result_of), the functions template
+ Function return types (i.e., result_of), the functions template
mem_fn (a generalization of mem_fun and mem_fun_red), function
- object binders (e.g, bind, a generalization of bind1st and bind2nd),
- and polymorhpic function wrappers (e.g, class template function).
+ object binders (e.g., bind, a generalization of bind1st and bind2nd),
+ and polymorphic function wrappers (e.g, class template function).
</p>
<p><strong>Type traits - Complete -</strong>
@@ -1019,7 +1019,7 @@
</p>
<p><strong>A random number engine - Complete -</strong>
- This library contains randow number generators with several different
+ This library contains random number generators with several different
choices of distribution.
</p>
Index: docs/doxygen/tables.html
===================================================================
--- docs/doxygen/tables.html (Revision 119961)
+++ docs/doxygen/tables.html (Arbeitskopie)
@@ -18,7 +18,7 @@
</p>
<p>We will not try to duplicate all of the surrounding text (footnotes,
- explanations, etc) from the standard, because that would also entail a
+ explanations, etc.) from the standard, because that would also entail a
duplication of effort. Some of the surrounding text has been paraphrased
here for clarity. If you are uncertain about the meaning or interpretation
of these notes, consult a good textbook, and/or purchase your own copy of
@@ -589,7 +589,7 @@
<tr>
<td>a.clear()</td>
<td>void</td>
-<td>erases everthing; post: size() == 0</td>
+<td>erases everything; post: size() == 0</td>
<td>linear</td> <!-- DR 224 -->
</tr>
More information about the Gcc-patches
mailing list