diff options
Diffstat (limited to 'libstdc++-v3/docs')
| -rw-r--r-- | libstdc++-v3/docs/doxygen/tables.html | 4 | ||||
| -rw-r--r-- | libstdc++-v3/docs/html/17_intro/howto.html | 4 | ||||
| -rw-r--r-- | libstdc++-v3/docs/html/17_intro/porting-howto.xml | 2 | ||||
| -rw-r--r-- | libstdc++-v3/docs/html/18_support/howto.html | 2 | ||||
| -rw-r--r-- | libstdc++-v3/docs/html/21_strings/howto.html | 4 | ||||
| -rw-r--r-- | libstdc++-v3/docs/html/22_locale/howto.html | 2 | ||||
| -rw-r--r-- | libstdc++-v3/docs/html/24_iterators/howto.html | 2 | ||||
| -rw-r--r-- | libstdc++-v3/docs/html/27_io/howto.html | 8 | ||||
| -rw-r--r-- | libstdc++-v3/docs/html/ext/ballocator_doc.html | 20 | ||||
| -rw-r--r-- | libstdc++-v3/docs/html/ext/howto.html | 2 | ||||
| -rw-r--r-- | libstdc++-v3/docs/html/faq/index.html | 14 |
11 files changed, 32 insertions, 32 deletions
diff --git a/libstdc++-v3/docs/doxygen/tables.html b/libstdc++-v3/docs/doxygen/tables.html index 370c6ce..74ac3e2 100644 --- a/libstdc++-v3/docs/doxygen/tables.html +++ b/libstdc++-v3/docs/doxygen/tables.html @@ -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> diff --git a/libstdc++-v3/docs/html/17_intro/howto.html b/libstdc++-v3/docs/html/17_intro/howto.html index ab65424..631e58f 100644 --- a/libstdc++-v3/docs/html/17_intro/howto.html +++ b/libstdc++-v3/docs/html/17_intro/howto.html @@ -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 diff --git a/libstdc++-v3/docs/html/17_intro/porting-howto.xml b/libstdc++-v3/docs/html/17_intro/porting-howto.xml index cdffdcf..cea9111 100644 --- a/libstdc++-v3/docs/html/17_intro/porting-howto.xml +++ b/libstdc++-v3/docs/html/17_intro/porting-howto.xml @@ -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> diff --git a/libstdc++-v3/docs/html/18_support/howto.html b/libstdc++-v3/docs/html/18_support/howto.html index eff1c75..7b1dcb8 100644 --- a/libstdc++-v3/docs/html/18_support/howto.html +++ b/libstdc++-v3/docs/html/18_support/howto.html @@ -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: diff --git a/libstdc++-v3/docs/html/21_strings/howto.html b/libstdc++-v3/docs/html/21_strings/howto.html index ed2e743..a356667 100644 --- a/libstdc++-v3/docs/html/21_strings/howto.html +++ b/libstdc++-v3/docs/html/21_strings/howto.html @@ -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 diff --git a/libstdc++-v3/docs/html/22_locale/howto.html b/libstdc++-v3/docs/html/22_locale/howto.html index 30e1e1f..3d19bb6 100644 --- a/libstdc++-v3/docs/html/22_locale/howto.html +++ b/libstdc++-v3/docs/html/22_locale/howto.html @@ -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. diff --git a/libstdc++-v3/docs/html/24_iterators/howto.html b/libstdc++-v3/docs/html/24_iterators/howto.html index e4d557d..43d199d 100644 --- a/libstdc++-v3/docs/html/24_iterators/howto.html +++ b/libstdc++-v3/docs/html/24_iterators/howto.html @@ -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 diff --git a/libstdc++-v3/docs/html/27_io/howto.html b/libstdc++-v3/docs/html/27_io/howto.html index a9a3bbe..1472053 100644 --- a/libstdc++-v3/docs/html/27_io/howto.html +++ b/libstdc++-v3/docs/html/27_io/howto.html @@ -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>. diff --git a/libstdc++-v3/docs/html/ext/ballocator_doc.html b/libstdc++-v3/docs/html/ext/ballocator_doc.html index 7b1f4d2..fa09584 100644 --- a/libstdc++-v3/docs/html/ext/ballocator_doc.html +++ b/libstdc++-v3/docs/html/ext/ballocator_doc.html @@ -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 => 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> diff --git a/libstdc++-v3/docs/html/ext/howto.html b/libstdc++-v3/docs/html/ext/howto.html index 800f286..888591a 100644 --- a/libstdc++-v3/docs/html/ext/howto.html +++ b/libstdc++-v3/docs/html/ext/howto.html @@ -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>: diff --git a/libstdc++-v3/docs/html/faq/index.html b/libstdc++-v3/docs/html/faq/index.html index 48f11c0..3c907be 100644 --- a/libstdc++-v3/docs/html/faq/index.html +++ b/libstdc++-v3/docs/html/faq/index.html @@ -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 "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 @@ 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> |