mirrors/gcc
0
0
Fork 0
mirror of https://gcc.gnu.org/git/gcc.git synced 2024-12-27 13:05:24 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

howto.html: Fix typos.

Browse Source 
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.

From-SVN: r119964
This commit is contained in:
Ralf Wildenhues 2006-12-16 17:16:04 +00:00 committed by Paolo Carlini
parent b3b433c507
commit e5c0ebd921
12 changed files with 46 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
libstdc++-v3/ChangeLog
View File

@ -1,3 +1,17 @@
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.
2006-12-13 Ian Lance Taylor <iant@google.com>
PR c++/19564

4
libstdc++-v3/docs/doxygen/tables.html
View File

@ -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 @@ examples of the latter are multiset and multimap.
<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>

4
libstdc++-v3/docs/html/17_intro/howto.html
View File

@ -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 &quot;the
implementation&quot; 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

2
libstdc++-v3/docs/html/17_intro/porting-howto.xml
View File

@ -363,7 +363,7 @@ o clean up the section-numbering
<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>

2
libstdc++-v3/docs/html/18_support/howto.html
View File

@ -125,7 +125,7 @@
<h3><code>&lt;limits&gt;</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:

4
libstdc++-v3/docs/html/21_strings/howto.html
View File

@ -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

2
libstdc++-v3/docs/html/22_locale/howto.html
View File

@ -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.

2
libstdc++-v3/docs/html/24_iterators/howto.html
View File

@ -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 &quot;meta-information&quot; that simply
tell the compiler some nicknames; they don't create code. That

8
libstdc++-v3/docs/html/27_io/howto.html
View File

@ -102,13 +102,13 @@
blank lines and only &quot;Thequickbrownfox...&quot;. 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
&quot;interesting&quot; problems.
</p>
@ -643,7 +643,7 @@
interfaces, then you only need to use the appropriate interface header.
</p>
<p><strong>&lt;iomanip&gt;</strong> provides &quot;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,&quot; such as std::setprecision and std::setw. If you need
to write expressions like <code>os &lt;&lt; setw(3);</code> or
<code>is &gt;&gt; setbase(8);</code>, you must include &lt;iomanip&gt;.

20
libstdc++-v3/docs/html/ext/ballocator_doc.html
View File

@ -40,7 +40,7 @@ will double every time the bitmapped allocator runs out of memory.<br>
<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 @@ operator new.<br>
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 @@ which is 8-bytes, or 2 x sizeof(size_t).<br>
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 @@ some linear/logarithmic complexity components in it. Thus, to try and
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 @@ bitmap is a multiple of 32 in size. If there are 32 x (2^3) blocks of
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 @@ field indicates free, while a 0 indicates allocated. This lets us check
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 @@ Where,<br>
k =&gt; The constant overhead per node. eg. for list, it is 8 bytes,
and for map it is 12 bytes.<br>
c =&gt; 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>

2
libstdc++-v3/docs/html/ext/howto.html
View File

@ -387,7 +387,7 @@
<em>operator&gt;&gt;(istream&amp;, string&amp;) doesn't set failbit</em>
</dt>
<dd>If nothing is extracted into the string, <code>op&gt;&gt;</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>:

14
libstdc++-v3/docs/html/faq/index.html
View File

@ -250,7 +250,7 @@ which is no longer available, thanks deja...-->
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 &quot;useful stuff&quot;
time.) It is entirely plausible that the &quot;useful stuff&quot;
from libg++ might be extracted into an updated utilities library,
but nobody has started such a project yet.
</p>
@ -504,7 +504,7 @@ which is no longer available, thanks deja...-->
<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 @@ which is no longer available, thanks deja...-->
<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 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
</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 @@ http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff
</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>