ChangeLog, [...]: Fix spelling errors.
* ChangeLog, docs/doxygen/maint.cfg.in, docs/doxygen/user.cfg.in, docs/doxygen/doxygroups.cc, docs/doxygen/Intro.3, docs/html/17_intro/BUGS, docs/html/17_intro/C++STYLE, docs/html/17_intro/CHECKLIST, docs/html/17_intro/DESIGN, docs/html/17_intro/howto.html, docs/html/17_intro/porting.html, docs/html/17_intro/porting.texi, docs/html/18_support/howto.html, docs/html/19_diagnostics/howto.html, docs/html/20_util/howto.html, docs/html/21_strings/howto.html, docs/html/23_containers/howto.html, docs/html/26_numerics/howto.html, docs/html/27_io/howto.html, docs/html/27_io/binary_iostreams_kuehl.txt, docs/html/ext/sgiexts.html, docs/html/faq/index.html, docs/html/faq/index.txt, testsuite/24_iterators/iterator.cc, include/bits/basic_file.h, include/bits/locale_facets.h, include/bits/locale_facets.tcc, include/bits/std_sstream.h, include/ext/ropeimpl.h, include/ext/stl_rope.h, libsupc++/tinfo.cc, libsupc++/cxxabi.h, libsupc++/typeinfo, libsupc++/eh_throw.cc, acinclude.m4, aclocal.m4, configure, configure.target, ChangeLog-2000: Fix spelling errors. From-SVN: r47291
This commit is contained in:
parent
eac50d7a73
commit
c5504edb75
|
@ -1,5 +1,25 @@
|
|||
2001-11-23 Joseph S. Myers <jsm28@cam.ac.uk>
|
||||
|
||||
* ChangeLog, docs/doxygen/maint.cfg.in, docs/doxygen/user.cfg.in,
|
||||
docs/doxygen/doxygroups.cc, docs/doxygen/Intro.3,
|
||||
docs/html/17_intro/BUGS, docs/html/17_intro/C++STYLE,
|
||||
docs/html/17_intro/CHECKLIST, docs/html/17_intro/DESIGN,
|
||||
docs/html/17_intro/howto.html, docs/html/17_intro/porting.html,
|
||||
docs/html/17_intro/porting.texi, docs/html/18_support/howto.html,
|
||||
docs/html/19_diagnostics/howto.html, docs/html/20_util/howto.html,
|
||||
docs/html/21_strings/howto.html,
|
||||
docs/html/23_containers/howto.html,
|
||||
docs/html/26_numerics/howto.html, docs/html/27_io/howto.html,
|
||||
docs/html/27_io/binary_iostreams_kuehl.txt,
|
||||
docs/html/ext/sgiexts.html, docs/html/faq/index.html,
|
||||
docs/html/faq/index.txt, testsuite/24_iterators/iterator.cc,
|
||||
include/bits/basic_file.h, include/bits/locale_facets.h,
|
||||
include/bits/locale_facets.tcc, include/bits/std_sstream.h,
|
||||
include/ext/ropeimpl.h, include/ext/stl_rope.h,
|
||||
libsupc++/tinfo.cc, libsupc++/cxxabi.h, libsupc++/typeinfo,
|
||||
libsupc++/eh_throw.cc, acinclude.m4, aclocal.m4, configure,
|
||||
configure.target, ChangeLog-2000: Fix spelling errors.
|
||||
|
||||
* config/locale/moneypunct_members_gnu.cc,
|
||||
include/bits/locale_facets.h: Fix spelling errors.
|
||||
|
||||
|
|
|
@ -873,7 +873,7 @@
|
|||
2000-11-23 Gabriel Dos Reis <gdr@codesourcery.com>
|
||||
|
||||
* include/bits/ios_base.h (ios_base::failure::~failure,
|
||||
ios_base::failure::what): Move defintion to ...
|
||||
ios_base::failure::what): Move definition to ...
|
||||
|
||||
* src/ios.cc (ios_base::failure::~failure): ... here.
|
||||
src/ios.cc (ios::failure::what): Likewise.
|
||||
|
@ -2043,7 +2043,7 @@ Thu Nov 2 10:11:45 2000 Mark P Mitchell <mark@codesourcery.com>
|
|||
|
||||
* acinclude.m4 (GLIBCPP_CHECK_OS): Link to os_defines.h.
|
||||
* aclocal.m4: Regenerate.
|
||||
* config/os/*/bits/os_defintes: Adjust copyright dates.
|
||||
* config/os/*/bits/os_defines: Adjust copyright dates.
|
||||
|
||||
2000-10-08 Phil Edwards <pme@sources.redhat.com>
|
||||
|
||||
|
@ -2768,7 +2768,7 @@ Thu Nov 2 10:11:45 2000 Mark P Mitchell <mark@codesourcery.com>
|
|||
__codecvt_abstract_base in an attempt to point some light this way...
|
||||
Move __enc_traits and codecvt bits to codecvt.h.
|
||||
* src/locale-inst.cc: Remove codecvt<wchar_t, wchar_t, mbstate_t>
|
||||
explicit instantiation. Separate out codecvt instantations, simplify.
|
||||
explicit instantiation. Separate out codecvt instantiations, simplify.
|
||||
* src/locale.cc: Move codecvt bits to codecvt.cc
|
||||
|
||||
2000-08-15 Alexandre Oliva <aoliva@redhat.com>
|
||||
|
@ -4796,7 +4796,7 @@ Thu Nov 2 10:11:45 2000 Mark P Mitchell <mark@codesourcery.com>
|
|||
(ctype<wchar_t>): Same.
|
||||
Move _S_touppper to _M_toupper and initialize in ctor.
|
||||
Move _S_tolower to _M_tolower and initialize in ctor.
|
||||
Move _S_table to _M_ctable and intialize in ctor.
|
||||
Move _S_table to _M_ctable and initialize in ctor.
|
||||
* bits/locale_facets.h (std): And here.
|
||||
* src/locale.cc (std): Tweak.
|
||||
* config/gnu-linux/ctype.cc: Change initialization here.
|
||||
|
@ -4807,7 +4807,7 @@ Thu Nov 2 10:11:45 2000 Mark P Mitchell <mark@codesourcery.com>
|
|||
* bits/localefwd.h: Tweak.
|
||||
* bits/std_streambuf.h: Tweak formatting.
|
||||
|
||||
* testsuite/27_io/filebuf.cc: Remove BUFSIZ dependancies.
|
||||
* testsuite/27_io/filebuf.cc: Remove BUFSIZ dependencies.
|
||||
|
||||
2000-03-05 Chip Salzenberg <chip@valinux.com>
|
||||
|
||||
|
@ -4822,7 +4822,7 @@ Thu Nov 2 10:11:45 2000 Mark P Mitchell <mark@codesourcery.com>
|
|||
* std/strstream: New file.
|
||||
* stl/bits/std_strstream.h: New file.
|
||||
* bits/std_streambuf.h: Add public access.
|
||||
* src/Makefile.am: Add strstream sources to list of dependancies.
|
||||
* src/Makefile.am: Add strstream sources to list of dependencies.
|
||||
* src/Makefile.in: Regenerate.
|
||||
|
||||
2000-03-03 2000 Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr>
|
||||
|
@ -5318,7 +5318,7 @@ Thu Nov 2 10:11:45 2000 Mark P Mitchell <mark@codesourcery.com>
|
|||
* math/complex-stub.h (nan): And here.
|
||||
|
||||
* Makefile.am (rebuild-stamp): Remove libio and libio
|
||||
dependancies. Plan to take out libio subdir and just merge with
|
||||
dependencies. Plan to take out libio subdir and just merge with
|
||||
libio in top level gcc directory. Of course, this assumes there is
|
||||
a libio in the top level directory (ie ../src_dir). This will
|
||||
probably change the way this library is configured by default.
|
||||
|
@ -5928,7 +5928,7 @@ Thu Nov 2 10:11:45 2000 Mark P Mitchell <mark@codesourcery.com>
|
|||
1999-12-08 Benjamin Kosnik <bkoz@cygnus.com>
|
||||
|
||||
* bits/sstream.tcc (stringbuf::seekoff): Long overdue revamp. Make
|
||||
in and out buffers update independantly.
|
||||
in and out buffers update independently.
|
||||
|
||||
* bits/basic_ios.h: Minor formatting.
|
||||
* bits/fstream.tcc (std): Fix indentation.
|
||||
|
@ -7161,7 +7161,7 @@ Thu Nov 2 10:11:45 2000 Mark P Mitchell <mark@codesourcery.com>
|
|||
* bits/std_sstream.h (_M_init_stringbuf): New function.
|
||||
* bits/sstream.tcc: Tweak.
|
||||
|
||||
* docs/27_io/iostreams_heirarchy.pdf: New file.
|
||||
* docs/27_io/iostreams_hierarchy.pdf: New file.
|
||||
|
||||
* docs/17_intro/CHECKLIST (basic_string<char>): Validation and
|
||||
acceptance. Wooo-hoo!
|
||||
|
@ -7611,7 +7611,7 @@ Thu Nov 2 10:11:45 2000 Mark P Mitchell <mark@codesourcery.com>
|
|||
converting "long double" to struct long_double. Probably should be
|
||||
done with one macro (HAVE_STRTOLD) at configure time.
|
||||
|
||||
* bits/std_cmath.h: Comment out pow(double, int) defintion as
|
||||
* bits/std_cmath.h: Comment out pow(double, int) definition as
|
||||
gives re-declaration under hpux10.20. Revert previous change, as
|
||||
kills linux/x86, solaris 2.7, hpux builds. These should be done
|
||||
using autoconf, see std_cctype.h and the solutions started in
|
||||
|
@ -8804,7 +8804,7 @@ Thu Nov 2 10:11:45 2000 Mark P Mitchell <mark@codesourcery.com>
|
|||
|
||||
* bits/char_traits.h: Remove fpos definitions from here. . .
|
||||
* bits/fpos.h: New file, put them here. Eventually, this may allow
|
||||
the severing of char_traits and fpos dependancies.
|
||||
the severing of char_traits and fpos dependencies.
|
||||
* src/Makefile.in: Add fpos.h.
|
||||
* src/Makefile.am: Ditto.
|
||||
* bits/std_string.h: Add fpos.h include here.
|
||||
|
@ -9698,7 +9698,7 @@ Thu Nov 2 10:11:45 2000 Mark P Mitchell <mark@codesourcery.com>
|
|||
|
||||
* bits/basic_string.h: Disable non-standard ctor declarations.
|
||||
* bits/string.tcc: Disable definitions as well.
|
||||
* src/string.cc: Disable <ios> dependancies.
|
||||
* src/string.cc: Disable <ios> dependencies.
|
||||
* bits/sbuf_iter.h (std): Add default to template parameter for
|
||||
ostreambuf_iterator and istreambuf_iterator.
|
||||
* bits/std_iosfwd.h: Change istreambuf_iterator to
|
||||
|
|
|
@ -173,8 +173,8 @@ LIB_AC_PROG_CXX
|
|||
# at least currently, we never actually build a program, so we never
|
||||
# need to use $(EXEEXT). Moreover, the test for EXEEXT normally
|
||||
# fails, because we are probably configuring with a cross compiler
|
||||
# which cant create executables. So we include AC_EXEEXT to keep
|
||||
# automake happy, but we dont execute it, since we dont care about
|
||||
# which can't create executables. So we include AC_EXEEXT to keep
|
||||
# automake happy, but we don't execute it, since we don't care about
|
||||
# the result.
|
||||
if false; then
|
||||
# autoconf 2.50 runs AC_EXEEXT by default, and the macro expands
|
||||
|
|
|
@ -185,8 +185,8 @@ LIB_AC_PROG_CXX
|
|||
# at least currently, we never actually build a program, so we never
|
||||
# need to use $(EXEEXT). Moreover, the test for EXEEXT normally
|
||||
# fails, because we are probably configuring with a cross compiler
|
||||
# which cant create executables. So we include AC_EXEEXT to keep
|
||||
# automake happy, but we dont execute it, since we dont care about
|
||||
# which can't create executables. So we include AC_EXEEXT to keep
|
||||
# automake happy, but we don't execute it, since we don't care about
|
||||
# the result.
|
||||
if false; then
|
||||
# autoconf 2.50 runs AC_EXEEXT by default, and the macro expands
|
||||
|
|
|
@ -1627,8 +1627,8 @@ fi
|
|||
# at least currently, we never actually build a program, so we never
|
||||
# need to use $(EXEEXT). Moreover, the test for EXEEXT normally
|
||||
# fails, because we are probably configuring with a cross compiler
|
||||
# which cant create executables. So we include AC_EXEEXT to keep
|
||||
# automake happy, but we dont execute it, since we dont care about
|
||||
# which can't create executables. So we include AC_EXEEXT to keep
|
||||
# automake happy, but we don't execute it, since we don't care about
|
||||
# the result.
|
||||
if false; then
|
||||
# autoconf 2.50 runs AC_EXEEXT by default, and the macro expands
|
||||
|
|
|
@ -113,7 +113,7 @@ case "${target_os}" in
|
|||
esac
|
||||
|
||||
|
||||
# Set any flags dependant on the full target triplet.
|
||||
# Set any flags dependent on the full target triplet.
|
||||
# THIS TABLE IS SORTED. KEEP IT THAT WAY.
|
||||
case "${target}" in
|
||||
*-*-aix[456789]*)
|
||||
|
|
|
@ -66,7 +66,7 @@ lB lB lB lB.
|
|||
<complex> <fstream> <memory> <vector>
|
||||
<csetjmp> <functional> <numeric>
|
||||
.TE
|
||||
.SS Backwards-Compatability Headers
|
||||
.SS Backwards-Compatibility Headers
|
||||
For GCC 3.0 these headers will be found automatically, unless you instruct
|
||||
the compiler otherwise. You should not depend on this, instead you should
|
||||
read FAQ 5.4 and use a
|
||||
|
|
|
@ -67,7 +67,7 @@ following:
|
|||
As an example of the first case, @c vector is required to use a contiguous
|
||||
memory layout, while other sequences such as @c deque are not.
|
||||
|
||||
The prime reason for chosing one sequence over another should be based on
|
||||
The prime reason for choosing one sequence over another should be based on
|
||||
the second category of differences, algorithmic complexity. For example, if
|
||||
you need to perform many inserts and removals from the middle of a sequence,
|
||||
@c list would be ideal. But if you need to perform constant-time access to
|
||||
|
|
|
@ -140,7 +140,7 @@ STRIP_CODE_COMMENTS = YES
|
|||
# file names in lower case letters. If set to YES upper case letters are also
|
||||
# allowed. This is useful if you have classes or files whose names only differ
|
||||
# in case and if your file system supports case sensitive file names. Windows
|
||||
# users are adviced to set this option to NO.
|
||||
# users are advised to set this option to NO.
|
||||
|
||||
CASE_SENSE_NAMES = YES
|
||||
|
||||
|
|
|
@ -144,7 +144,7 @@ STRIP_CODE_COMMENTS = YES
|
|||
# file names in lower case letters. If set to YES upper case letters are also
|
||||
# allowed. This is useful if you have classes or files whose names only differ
|
||||
# in case and if your file system supports case sensitive file names. Windows
|
||||
# users are adviced to set this option to NO.
|
||||
# users are advised to set this option to NO.
|
||||
|
||||
CASE_SENSE_NAMES = NO
|
||||
|
||||
|
|
|
@ -5,7 +5,7 @@
|
|||
|
||||
- _GLIBCPP_HAS_BUILTIN_SINF: We should still hold out for a cleaner solution the is currenly the case in bits/std_cmath.h.
|
||||
|
||||
- there may be one set of remaining string bugs, dependant on final
|
||||
- there may be one set of remaining string bugs, dependent on final
|
||||
clarification of the string::find technicalities when finding in an
|
||||
empty string or using an empty string for an argument. At the very
|
||||
least, v-3 has interpreted the standard in a way that is in opposition
|
||||
|
|
|
@ -122,7 +122,7 @@ Notable areas of divergence from what may be previous local practice
|
|||
//
|
||||
}
|
||||
|
||||
09. Member functions declarations and defintions
|
||||
09. Member functions declarations and definitions
|
||||
Keywords such as extern, static, export, explicit, inline, etc
|
||||
go on the line above the function name. Thus
|
||||
|
||||
|
|
|
@ -958,7 +958,7 @@ T X* get() const throw();
|
|||
T X* release() throw();
|
||||
T void reset(X* p =0) throw();
|
||||
|
||||
// _lib.auto.ptr.conv_ converions:
|
||||
// _lib.auto.ptr.conv_ conversions:
|
||||
X auto_ptr(auto_ptr_ref<X>) throw();
|
||||
X template<class Y> operator auto_ptr_ref<Y>() throw();
|
||||
X template<class Y> operator auto_ptr<Y>() throw();
|
||||
|
|
|
@ -253,7 +253,7 @@ cases it may actually be excessive.
|
|||
|
||||
To implement a library which does not use exceptions directly is
|
||||
not difficult given minor compiler support (to "turn off" exceptions
|
||||
and ignore exception contructs), and results in no great library
|
||||
and ignore exception constructs), and results in no great library
|
||||
maintenance difficulties. To be precise, given "-fno-exceptions",
|
||||
the compiler should treat "try" blocks as ordinary blocks, and
|
||||
"catch" blocks as dead code to ignore or eliminate. Compiler
|
||||
|
|
|
@ -124,7 +124,7 @@
|
|||
</p>
|
||||
<p>Here is a small link farm to threads (no pun) in the mail archives
|
||||
that discuss the threading problem. Each link is to the first
|
||||
relevent message in the thread; from there you can use
|
||||
relevant message in the thread; from there you can use
|
||||
"Thread Next" to move down the thread. This farm is in
|
||||
latest-to-oldest order.
|
||||
<ul>
|
||||
|
@ -142,7 +142,7 @@
|
|||
(A large selection of links to older messages has been removed; many
|
||||
of the messages from 1999 were lost in a disk crash, and the few
|
||||
people with access to the backup tapes have been too swamped with work
|
||||
to restore them. Many of the points have been superceded anyhow.)
|
||||
to restore them. Many of the points have been superseded anyhow.)
|
||||
</p>
|
||||
<p>This section will be updated as new and interesting issues come
|
||||
to light.
|
||||
|
|
|
@ -140,7 +140,7 @@ Up:<a rel=up href="#Top">Top</a>
|
|||
<h1>Character types</h1>
|
||||
|
||||
<p>The library requires that you provide three header files to implement
|
||||
character classification, analagous to that provided by the C libraries
|
||||
character classification, analogous to that provided by the C libraries
|
||||
<code><ctype.h></code> header. You can model these on the files provided in
|
||||
<code>config/os/generic/bits</code>. However, these files will almost
|
||||
certainly need some modification.
|
||||
|
@ -149,7 +149,7 @@ certainly need some modification.
|
|||
some very basic information about character classification. The libstdc++-v3
|
||||
library assumes that your C library implements <code><ctype.h></code> by using
|
||||
a table (indexed by character code) containing integers, where each of
|
||||
these integers is a bit-mask indicating whether the charcter is
|
||||
these integers is a bit-mask indicating whether the character is
|
||||
upper-case, lower-case, alphabetic, etc. The <code>bits/ctype_base.h</code>
|
||||
file gives the type of the integer, and the values of the various bit
|
||||
masks. You will have to peer at your own <code><ctype.h></code> to figure out
|
||||
|
@ -273,7 +273,7 @@ contains a few more functions. On most systems, you can just copy
|
|||
<code>config/os/generic/ctype_inline.h</code> and use it on your system.
|
||||
|
||||
<p>In detail, the functions provided test characters for particular
|
||||
properties; they are analagous to the functions like <code>isalpha</code> and
|
||||
properties; they are analogous to the functions like <code>isalpha</code> and
|
||||
<code>islower</code> provided by the C library.
|
||||
|
||||
<p>The first function is implemented like this on IRIX:
|
||||
|
|
|
@ -176,7 +176,7 @@ starting point.
|
|||
@chapter Character types
|
||||
|
||||
The library requires that you provide three header files to implement
|
||||
character classification, analagous to that provided by the C libraries
|
||||
character classification, analogous to that provided by the C libraries
|
||||
@file{<ctype.h>} header. You can model these on the files provided in
|
||||
@file{config/os/generic/bits}. However, these files will almost
|
||||
certainly need some modification.
|
||||
|
@ -185,7 +185,7 @@ The first file to write is @file{bits/ctype_base.h}. This file provides
|
|||
some very basic information about character classification. The libstdc++-v3
|
||||
library assumes that your C library implements @file{<ctype.h>} by using
|
||||
a table (indexed by character code) containing integers, where each of
|
||||
these integers is a bit-mask indicating whether the charcter is
|
||||
these integers is a bit-mask indicating whether the character is
|
||||
upper-case, lower-case, alphabetic, etc. The @file{bits/ctype_base.h}
|
||||
file gives the type of the integer, and the values of the various bit
|
||||
masks. You will have to peer at your own @file{<ctype.h>} to figure out
|
||||
|
@ -316,7 +316,7 @@ contains a few more functions. On most systems, you can just copy
|
|||
@file{config/os/generic/ctype_inline.h} and use it on your system.
|
||||
|
||||
In detail, the functions provided test characters for particular
|
||||
properties; they are analagous to the functions like @code{isalpha} and
|
||||
properties; they are analogous to the functions like @code{isalpha} and
|
||||
@code{islower} provided by the C library.
|
||||
|
||||
The first function is implemented like this on IRIX:
|
||||
|
|
|
@ -182,7 +182,7 @@
|
|||
atexit(f2);
|
||||
</pre>then at a call of <code>exit()</code>, f2 will be called, then
|
||||
obj2 will be destroyed, then f1 will be called, and finally obj1
|
||||
will be destroyed. If f1 or f2 allow an exception to propogate
|
||||
will be destroyed. If f1 or f2 allow an exception to propagate
|
||||
out of them, Bad Things happen.
|
||||
</ol>
|
||||
</p>
|
||||
|
|
|
@ -37,7 +37,7 @@
|
|||
<p>The standard exception classes carry with them a single string as
|
||||
data (usually describing what went wrong or where the 'throw' took
|
||||
place). It's good to remember that you can add your own data to
|
||||
these exceptions when extending the heirarchy:
|
||||
these exceptions when extending the hierarchy:
|
||||
</p>
|
||||
<pre>
|
||||
struct My_Exception : public std::runtime_error
|
||||
|
|
|
@ -91,7 +91,7 @@
|
|||
<h2><a name="2"><code>auto_ptr</code> inside container classes</a></h2>
|
||||
<p>All of the <a href="../23_containers/howto.html">containers</a>
|
||||
described in the standard library require their contained types
|
||||
to have, among other things, a copy contructor like this:
|
||||
to have, among other things, a copy constructor like this:
|
||||
<pre>
|
||||
struct My_Type
|
||||
{
|
||||
|
|
|
@ -37,7 +37,7 @@
|
|||
CString. Often programmers realize that a standard portable
|
||||
answer is better than a proprietary nonportable one, but in porting
|
||||
their application from a Win32 platform, they discover that they
|
||||
are relying on special functons offered by the CString class.
|
||||
are relying on special functions offered by the CString class.
|
||||
</p>
|
||||
<p>Things are not as bad as they seem. In
|
||||
<a href="http://gcc.gnu.org/ml/gcc/1999-04n/msg00236.html">this
|
||||
|
@ -58,7 +58,7 @@
|
|||
stringstream classes. These are the bridge between the iostream
|
||||
hierarchy and the string class, and they operate with regular
|
||||
streams seamlessly because they inherit from the iostream
|
||||
heirarchy. An quick example:
|
||||
hierarchy. An quick example:
|
||||
<pre>
|
||||
#include <iostream>
|
||||
#include <string>
|
||||
|
@ -315,7 +315,7 @@
|
|||
str.erase(notwhite+1); </pre>
|
||||
Obviously, the calls to <code>find</code> could be inserted directly
|
||||
into the calls to <code>erase</code>, in case your compiler does not
|
||||
optimize named temporaries out of existance.
|
||||
optimize named temporaries out of existence.
|
||||
</p>
|
||||
<p>Return <a href="#top">to top of page</a> or
|
||||
<a href="../faq/index.html">to the FAQ</a>.
|
||||
|
|
|
@ -165,7 +165,7 @@
|
|||
<code>bitset</code>
|
||||
for the required number of bits, inside some wrapper functions with
|
||||
unchanging signatures. Have your program then call the
|
||||
compiler on that file using Position Independant Code, then open the
|
||||
compiler on that file using Position Independent Code, then open the
|
||||
newly-created object file and load those wrapper functions. You'll have
|
||||
an instantiation of <code>bitset<N></code> for the exact
|
||||
<code>N</code>
|
||||
|
@ -324,7 +324,7 @@
|
|||
be the entry in the container pointed to by <code>hint</code>, that
|
||||
is, <code>h = *hint</code>. Then the item being inserted should have
|
||||
a key less than that of <code>h</code>, and greater than that of the
|
||||
item preceeding <code>h</code>. The new item will be inserted
|
||||
item preceding <code>h</code>. The new item will be inserted
|
||||
between <code>h</code> and <code>h</code>'s predecessor.
|
||||
</ul>
|
||||
</p>
|
||||
|
|
|
@ -133,7 +133,7 @@
|
|||
<p>The C99 features depend on the <code>--enable-c99</code> configure flag.
|
||||
This flag is already on by default, but it can be disabled by the
|
||||
user. Also, the configuration machinery will disable it if the
|
||||
neccessary support for C99 (e.g., header files) cannot be found.
|
||||
necessary support for C99 (e.g., header files) cannot be found.
|
||||
</p>
|
||||
<p>As of GCC 3.0, C99 support includes classification functions
|
||||
such as <code>isnormal</code>, <code>isgreater</code>,
|
||||
|
|
|
@ -80,7 +80,7 @@ on the streams level.
|
|||
|
||||
When I wrote the above paragraph about confirming your choice, I haven't
|
||||
read this question! As I said above: You told us what solution you have
|
||||
choosen without stating what problem is solved. We cannot determine
|
||||
chosen without stating what problem is solved. We cannot determine
|
||||
whether your choice is the right one. Actually, I'm pretty sure it is
|
||||
the wrong one but without seen the details I can't be certain.
|
||||
--
|
||||
|
|
|
@ -113,7 +113,7 @@
|
|||
when the output stream is, in fact, a terminal and not a file
|
||||
or some other device -- and <em>that</em> may not even be true
|
||||
since C++ says nothing about files nor terminals. All of that is
|
||||
system-dependant. (The "newline-buffer-flushing only occuring
|
||||
system-dependent. (The "newline-buffer-flushing only occurring
|
||||
on terminals" thing is mostly true on Unix systems, though.)
|
||||
</p>
|
||||
<p>Some people also believe that sending <code>endl</code> down an
|
||||
|
@ -167,7 +167,7 @@
|
|||
arguments are the same as those for the Standard C I/O Library
|
||||
function (a buffer area followed by its size).
|
||||
</p>
|
||||
<p>A great deal of this is implementation-dependant. For example,
|
||||
<p>A great deal of this is implementation-dependent. For example,
|
||||
<code>streambuf</code> does not specify any actions for its own
|
||||
<code>setbuf()</code>-ish functions; the classes derived from
|
||||
<code>streambuf</code> each define behavior that "makes
|
||||
|
@ -183,7 +183,7 @@
|
|||
<p>A last reminder: there are usually more buffers involved than
|
||||
just those at the language/library level. Kernel buffers, disk
|
||||
buffers, and the like will also have an effect. Inspecting and
|
||||
changing those are system-dependant.
|
||||
changing those are system-dependent.
|
||||
</p>
|
||||
<p>Return <a href="#top">to top of page</a> or
|
||||
<a href="../faq/index.html">to the FAQ</a>.
|
||||
|
@ -445,7 +445,7 @@
|
|||
</pre>
|
||||
</p>
|
||||
<p>You must do this before performing any I/O via the C++ stream objects.
|
||||
Once you call this, the C++ streams will operate independantly of the
|
||||
Once you call this, the C++ streams will operate independently of the
|
||||
(unused) C streams. For GCC 3.0, this means that <code>cout</code> and
|
||||
company will become fully buffered on their own.
|
||||
</p>
|
||||
|
|
|
@ -25,7 +25,7 @@ libstdc++-v3</a></h1>
|
|||
for a description). Not every chapter may have extensions, and the
|
||||
extensions may come and go. Also, this page is incomplete because the
|
||||
author is pressed for time. Check back often; the latest change was on
|
||||
$Date: 2001/10/09 20:18:13 $ (UTC).
|
||||
$Date: 2001/10/11 18:41:47 $ (UTC).
|
||||
</p>
|
||||
|
||||
<p>Descriptions range from the scanty to the verbose. You should also check
|
||||
|
@ -83,7 +83,7 @@ libstdc++-v3</a></h1>
|
|||
|
||||
<hr>
|
||||
<a name="ch23"><h3>Chapter 23</h3></a>
|
||||
<p>A few extensions and nods to backwards-compatability have been made with
|
||||
<p>A few extensions and nods to backwards-compatibility have been made with
|
||||
containers. Those dealing with older SGI-style allocators are dealt with
|
||||
elsewhere. The remaining ones all deal with bits:
|
||||
</p>
|
||||
|
|
|
@ -137,7 +137,7 @@ http://gcc.gnu.org/onlinedocs/libstdc++/faq/</a>.</p>
|
|||
(such as <code>string</code>, <code>vector<></code>, iostreams,
|
||||
and algorithms) will be freely available and fully compliant.
|
||||
Programmers will no longer need to "roll their own"
|
||||
nor be worried about platform-specific incompatabilities.
|
||||
nor be worried about platform-specific incompatibilities.
|
||||
</p>
|
||||
|
||||
<hr>
|
||||
|
@ -390,7 +390,7 @@ which is no longer available, thanks deja...-->
|
|||
</p>
|
||||
<p>Since the goal of ISO Standardization is for all C++
|
||||
implementations to be able to share code, the final libstdc++
|
||||
should, in theory, be useable under any ISO-compliant
|
||||
should, in theory, be usable under any ISO-compliant
|
||||
compiler. It will still be targeted and optimized for
|
||||
GCC/g++, however.
|
||||
</p>
|
||||
|
|
|
@ -89,7 +89,7 @@
|
|||
That means that all of the Standard classes and functions (such as
|
||||
string, vector<>, iostreams, and algorithms) will be freely available
|
||||
and fully compliant. Programmers will no longer need to "roll their
|
||||
own" nor be worried about platform-specific incompatabilities.
|
||||
own" nor be worried about platform-specific incompatibilities.
|
||||
_________________________________________________________________
|
||||
|
||||
1.3 Who's in charge of it?
|
||||
|
@ -314,7 +314,7 @@
|
|||
|
||||
Since the goal of ISO Standardization is for all C++ implementations
|
||||
to be able to share code, the final libstdc++ should, in theory, be
|
||||
useable under any ISO-compliant compiler. It will still be targeted
|
||||
usable under any ISO-compliant compiler. It will still be targeted
|
||||
and optimized for GCC/g++, however.
|
||||
_________________________________________________________________
|
||||
|
||||
|
|
|
@ -254,7 +254,7 @@ namespace std
|
|||
};
|
||||
} // namespace std
|
||||
|
||||
// Now include the bits that are dependant on the underlying I/O
|
||||
// Now include the bits that are dependent on the underlying I/O
|
||||
// model chosen at configure time.
|
||||
#include <bits/basic_file_model.h>
|
||||
|
||||
|
|
|
@ -502,7 +502,7 @@ namespace std
|
|||
|
||||
~_Format_cache() throw() { }
|
||||
|
||||
// Given a member of the ios heirarchy as an argument, extract
|
||||
// Given a member of the ios hierarchy as an argument, extract
|
||||
// out all the current formatting information into a
|
||||
// _Format_cache object and return a pointer to it.
|
||||
static _Format_cache<_CharT>*
|
||||
|
|
|
@ -1841,7 +1841,7 @@ namespace std
|
|||
// NB: In IEE 1003.1-200x, and perhaps other locale models, it
|
||||
// is possible that the format character will be longer than one
|
||||
// character. Possibilities include 'E' or 'O' followed by a
|
||||
// format charcter: if __mod is not the default argument, assume
|
||||
// format character: if __mod is not the default argument, assume
|
||||
// it's a valid modifier.
|
||||
char_type __fmt[4];
|
||||
__fmt[0] = __ctype.widen('%');
|
||||
|
|
|
@ -90,7 +90,7 @@ namespace std
|
|||
if (_M_mode & ios_base::out)
|
||||
{
|
||||
// This is the deal: _M_string.size() is a value that
|
||||
// represents the size of the intial string that makes
|
||||
// represents the size of the initial string that makes
|
||||
// _M_string, and may not be the correct size of the
|
||||
// current stringbuf internal buffer.
|
||||
__size_type __len = _M_string.size();
|
||||
|
|
|
@ -977,7 +977,7 @@ rope<_CharT,_Alloc>::_S_flatten(_RopeRep* __r, _CharT* __buffer)
|
|||
}
|
||||
case _RopeRep::_S_function:
|
||||
case _RopeRep::_S_substringfn:
|
||||
// We dont yet do anything with substring nodes.
|
||||
// We don't yet do anything with substring nodes.
|
||||
// This needs to be fixed before ropefiles will work well.
|
||||
{
|
||||
_RopeFunction* __f = (_RopeFunction*)__r;
|
||||
|
|
|
@ -340,7 +340,7 @@ identity_element(_Rope_Concat_fn<_CharT, _Alloc>)
|
|||
// that doesn't work, since it makes it impossible to define generic
|
||||
// equality on rope iterators. According to the draft standard, the
|
||||
// template parameters for such an equality operator cannot be inferred
|
||||
// from the occurence of a member class as a parameter.
|
||||
// from the occurrence of a member class as a parameter.
|
||||
// (SGI compilers in fact allow this, but the __result wouldn't be
|
||||
// portable.)
|
||||
// Similarly, some of the static member functions are member functions
|
||||
|
@ -543,7 +543,7 @@ struct _Rope_RopeLeaf : public _Rope_RopeRep<_CharT,_Alloc> {
|
|||
public:
|
||||
// Apparently needed by VC++
|
||||
// The data fields of leaves are allocated with some
|
||||
// extra space, to accomodate future growth and for basic
|
||||
// extra space, to accommodate future growth and for basic
|
||||
// character types, to hold a trailing eos character.
|
||||
enum { _S_alloc_granularity = 8 };
|
||||
static size_t _S_rounded_up_size(size_t __n) {
|
||||
|
@ -845,7 +845,7 @@ class _Rope_iterator_base
|
|||
public:
|
||||
typedef _Alloc _allocator_type; // used in _Rope_rotate, VC++ workaround
|
||||
typedef _Rope_RopeRep<_CharT,_Alloc> _RopeRep;
|
||||
// Borland doesnt want this to be protected.
|
||||
// Borland doesn't want this to be protected.
|
||||
protected:
|
||||
enum { _S_path_cache_len = 4 }; // Must be <= 9.
|
||||
enum { _S_iterator_buf_len = 15 };
|
||||
|
@ -1321,7 +1321,7 @@ class rope : public _Rope_base<_CharT,_Alloc> {
|
|||
const _CharT* __iter, size_t __slen)
|
||||
// As above, but one reference to __r is about to be
|
||||
// destroyed. Thus the pieces may be recycled if all
|
||||
// relevent reference counts are 1.
|
||||
// relevant reference counts are 1.
|
||||
# ifdef __GC
|
||||
// We can't really do anything since refcounts are unavailable.
|
||||
{ return _S_concat_char_iter(__r, __iter, __slen); }
|
||||
|
|
|
@ -45,7 +45,7 @@
|
|||
#ifdef __cplusplus
|
||||
|
||||
// We use the compiler builtins __SIZE_TYPE__ and __PTRDIFF_TYPE__ instead of
|
||||
// std::size_t and std::ptrdiff_t respectively. This makes us independant of
|
||||
// std::size_t and std::ptrdiff_t respectively. This makes us independent of
|
||||
// the conformance level of <cstddef> and whether -fhonor-std was supplied.
|
||||
// <cstddef> is not currently available during compiler building anyway.
|
||||
// Including <stddef.h> would be wrong, as that would rudely place size_t in
|
||||
|
@ -363,7 +363,7 @@ protected:
|
|||
class __vmi_class_type_info : public __class_type_info {
|
||||
/* abi defined member variables */
|
||||
public:
|
||||
unsigned int __flags; /* details about the class heirarchy */
|
||||
unsigned int __flags; /* details about the class hierarchy */
|
||||
unsigned int __base_count; /* number of direct bases */
|
||||
__base_class_info const __base_info[1]; /* array of bases */
|
||||
/* The array of bases uses the trailing array struct hack
|
||||
|
|
|
@ -40,7 +40,7 @@ __gxx_exception_cleanup (_Unwind_Reason_Code code, _Unwind_Exception *exc)
|
|||
{
|
||||
__cxa_exception *header = __get_exception_header_from_ue (exc);
|
||||
|
||||
// If we havn't been caught by a foreign handler, then this is
|
||||
// If we haven't been caught by a foreign handler, then this is
|
||||
// some sort of unwind error. In that case just die immediately.
|
||||
if (code != _URC_FOREIGN_EXCEPTION_CAUGHT)
|
||||
__terminate (header->terminateHandler);
|
||||
|
|
|
@ -172,12 +172,12 @@ __vmi_class_type_info::
|
|||
{}
|
||||
|
||||
// __upcast_result is used to hold information during traversal of a class
|
||||
// heirarchy when catch matching.
|
||||
// hierarchy when catch matching.
|
||||
struct __class_type_info::__upcast_result
|
||||
{
|
||||
const void *dst_ptr; // pointer to caught object
|
||||
__sub_kind part2dst; // path from current base to target
|
||||
int src_details; // hints about the source type heirarchy
|
||||
int src_details; // hints about the source type hierarchy
|
||||
const __class_type_info *base_type; // where we found the target,
|
||||
// if in vbase the __class_type_info of vbase
|
||||
// if a non-virtual base then 1
|
||||
|
@ -189,14 +189,14 @@ struct __class_type_info::__upcast_result
|
|||
};
|
||||
|
||||
// __dyncast_result is used to hold information during traversal of a class
|
||||
// heirarchy when dynamic casting.
|
||||
// hierarchy when dynamic casting.
|
||||
struct __class_type_info::__dyncast_result
|
||||
{
|
||||
const void *dst_ptr; // pointer to target object or NULL
|
||||
__sub_kind whole2dst; // path from most derived object to target
|
||||
__sub_kind whole2src; // path from most derived object to sub object
|
||||
__sub_kind dst2src; // path from target to sub object
|
||||
int whole_details; // details of the whole class heirarchy
|
||||
int whole_details; // details of the whole class hierarchy
|
||||
|
||||
public:
|
||||
__dyncast_result (int details_ = __vmi_class_type_info::__flags_unknown_mask)
|
||||
|
@ -483,7 +483,7 @@ __do_dyncast (ptrdiff_t src2dst,
|
|||
|| !(result.whole_details & __diamond_shaped_mask)))
|
||||
{
|
||||
// We already found SRC_PTR as a base of most derived, and
|
||||
// either it was non-virtual, or the whole heirarchy is
|
||||
// either it was non-virtual, or the whole hierarchy is
|
||||
// not-diamond shaped. Therefore if it is in either choice, it
|
||||
// can only be in one of them, and we will already know.
|
||||
if (old_sub_kind == __unknown)
|
||||
|
|
|
@ -90,7 +90,7 @@ namespace std
|
|||
// type. Uniqueness must use the _name value, not object address.
|
||||
bool operator==(const type_info& __arg) const;
|
||||
#else
|
||||
/** Returns true if @c *this preceeds @c __arg in the implementation's
|
||||
/** Returns true if @c *this precedes @c __arg in the implementation's
|
||||
* collation order. */
|
||||
// In new abi we can rely on type_info's NTBS being unique,
|
||||
// and therefore address comparisons are sufficient.
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
// 24.1.5 Random accesss iterators
|
||||
// 24.1.5 Random access iterators
|
||||
// 24.3.1 Iterator traits
|
||||
// (basic_string and vector implementations)
|
||||
//
|
||||
|
|
Loading…
Reference in New Issue