index.txt

测试手写程序

   It's not a bug, and it's not really a problem. Nevertheless, some
   people don't like it, so here are two pseudo-solutions:

   If the only functions from libstdc++.a which you need are language
   support functions (those listed in [65]clause 18 of the standard,
   e.g., new and delete), then try linking against libsupc++.a (usually
   specifying -lsupc++ when calling g++ for the final link step will do
   it). This library contains only those support routines, one per object
   file. But if you are using anything from the rest of the library, such
   as IOStreams or vectors, then you'll still need pieces from
   libstdc++.a.

   The second method is one we hope to incorporate into the library build
   process. Some platforms can place each function and variable into its
   own section in a .o file. The GNU linker can then perform garbage
   collection on unused sections; this reduces the situation to only
   copying needed functions into the executable, as before, but all
   happens automatically.

   Unfortunately the garbage collection in GNU ld is buggy; sections
   (corresponding to functions and variables) which are used are
   mistakenly removed, leading to horrible crashes when your executable
   starts up. For the time being, this feature is not used when building
   the library.
     _________________________________________________________________

                         3.0 Platform-Specific Issues

3.1 Can libstdc++-v3 be used with <my favorite compiler>?

   Probably not. Yet.

   Because GCC advances so rapidly, development and testing of libstdc++
   is being done almost entirely under that compiler. If you are curious
   about whether other, lesser compilers (*grin*) support libstdc++, you
   are more than welcome to try. Configuring and building the library
   (see above) will still require certain tools, however. Also keep in
   mind that building libstdc++ does not imply that your compiler will be
   able to use all of the features found in the C++ Standard Library.

   Since the goal of ISO Standardization is for all C++ implementations
   to be able to share code, the final libstdc++ should, in theory, be
   usable under any ISO-compliant compiler. It will still be targeted and
   optimized for GCC/g++, however.
     _________________________________________________________________

3.2 [removed]

   This question has become moot and has been removed. The stub is here
   to preserve numbering (and hence links/bookmarks).
     _________________________________________________________________

3.3 [removed]

   This question has become moot and has been removed. The stub is here
   to preserve numbering (and hence links/bookmarks).
     _________________________________________________________________

3.4 I can't use 'long long' on Solaris

   By default we try to support the C99 long long type. This requires
   that certain functions from your C library be present.

   Up through release 3.0.2 the tests performed were too general, and
   this feature was disabled when it did not need to be. The most
   commonly reported platform affected was Solaris.

   This has been fixed for 3.0.3 and onwards.
     _________________________________________________________________

                          4.0 Known Bugs and Non-Bugs

   Note that this section can get rapdily 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.

   For 3.0.1, the most common "bug" is an apparently missing "../" in
   include/Makefile, resulting in files like gthr.h and gthr-single.h not
   being found.

   Please read [66]the configuration instructions for GCC, specifically
   the part about configuring in a separate build directory, and how
   strongly recommended it is. Building in the source directory is
   fragile, is rarely tested, and tends to break, as in this case. This
   was fixed for 3.0.2.

   Please do not report these as bugs. We know about them. Reporting this
   -- or any other problem that's already been fixed -- hinders the
   development of GCC, because we have to take time to respond to your
   report. Thank you.

4.1 What works already?

   This is a verbatim clip from the "Status" section of the RELEASE-NOTES
   for the latest snapshot. For a list of fixed bugs, see that file.
New in 3.0.96:
---
- more doxygen documentation.
- extensions moved out of namespace std
- HPUX long long support
- more string optimizations
- support for NetBSD cross compiles
- concept_check merge from boost
- header simplification
- named locale bug shakeout
- thread testsuite

New in 3.0.95:
---
- add S390, m68k, x86-64 support.
- doxygen documentation has been extended, including man pages.
- verbose terminate handling has been added.
- some libsupc++ tweaks
- warnings for deprecated headers now active.
- dejagnu testsuite preliminary documentation.
- dejagnu testsuite default.
- dejagnu testsuite cross compiler, multilib safe.
- long long iostreams on by default, rework of ISO C99 support.
- iterator re-write and testsuites.
- container testsuites.
- allocator revamp and testsuites.
- more concept-checking work.
- basic_string optimization and MT fixes.
- new limits implementation.
- update -fno-exceptions code, verify it works.
- full named locale support fpr all facets, choice of gnu,
  ieee_1003.1-200x (POSIX 2), or generic models. Full support depends
  on target OS and underlying "C" library support.
     _________________________________________________________________

4.2 Bugs in gcc/g++ (not libstdc++-v3)

   This is by no means meant to be complete nor exhaustive, but mentions
   some problems that users may encounter when building or using
   libstdc++. If you are experiencing one of these problems, you can find
   more information on the libstdc++ and the GCC mailing lists.

   Before reporting a bug, examine the [67]bugs database with the
   category set to "libstdc++". The BUGS file in the source tree also
   tracks known serious problems.
     * Debugging is problematic, due to bugs in line-number generation
       (mostly fixed in the compiler) and gdb lagging behind the compiler
       (lack of personnel). We recommend configuring the compiler using
       --with-dwarf2 if the DWARF2 debugging format is not already the
       default on your platform. Also, [68]changing your GDB settings can
       have a profound effect on your C++ debugging experiences. :-)
     _________________________________________________________________

4.3 Bugs in the C++ language/lib specification

   Yes, unfortunately, there are some. In a [69]message to the list,
   Nathan Myers announced that he has started a list of problems in the
   ISO C++ Standard itself, especially with regard to the chapters that
   concern the library. The list itself is [70]posted on his website.
   Developers who are having problems interpreting the Standard may wish
   to consult his notes.

   For those people who are not part of the ISO Library Group (i.e.,
   nearly all of us needing to read this page in the first place :-), a
   public list of the library defects is occasionally published [71]here.
   Some of these have resulted in [72]code changes.
     _________________________________________________________________

4.4 Things in libstdc++ that look like bugs

   There are things which are not bugs in the compiler (4.2) nor the
   language specification (4.3), but aren't really bugs in libstdc++,
   either. Really! Please do not report these as bugs.

   -Weffc++ The biggest of these is the quadzillions of warnings about
   the library headers emitted when -Weffc++ is used. Making libstdc++
   "-Weffc++-clean" is not a goal of the project, for a few reasons.
   Mainly, that option tries to enforce object-oriented programming,
   while the Standard Library isn't necessarily trying to be OO.

   reopening a stream fails Did I just say that -Weffc++ was our biggest
   false-bug report? I lied. (It used to be.) Today it seems to be
   reports that after executing a sequence like
    #include <fstream>
    ...
    std::fstream  fs("a_file");
    // .
    // . do things with fs...
    // .
    fs.close();
    fs.open("a_new_file");

   all operations on the re-opened fs will fail, or at least act very
   strangely. Yes, they often will, especially if fs reached the EOF
   state on the previous file. The reason is that the state flags are not
   cleared on a successful call to open(). The standard unfortunately did
   not specify behavior in this case, and to everybody's great sorrow,
   the [73]proposed LWG resolution (see DR #22) is to leave the flags
   unchanged. You must insert a call to fs.clear() between the calls to
   close() and open(), and then everything will work like we all expect
   it to work.

   rel_ops Another is the rel_ops namespace and the template comparison
   operator functions contained therein. If they become visible in the
   same namespace as other comparison functions (e.g., 'using' them and
   the <iterator> header), then you will suddenly be faced with huge
   numbers of ambiguity errors. This was discussed on the -v3 list;
   Nathan Myers [74]sums things up here.

  The g++-3 headers are not ours

   If you have found an extremely broken header file which is causing
   problems for you, look carefully before submitting a "high" priority
   bug report (which you probably shouldn't do anyhow; see the last
   paragraph of the page describing [75]the GCC bug database).

   If the headers are in ${prefix}/include/g++-3, or if the installed
   library's name looks like libstdc++-2.10.a or libstdc++-libc6-2.10.so,
   then you are using the old libstdc++-v2 library, which is nonstandard
   and unmaintained. Do not report problems with -v2 to the -v3 mailing
   list.

   Currently our header files are installed in ${prefix}/include/g++-v3
   (see the 'v'?). This may change with the next release of GCC, as it
   may be too confusing, but [76]the question has not yet been decided.

   glibc If you're on a GNU/Linux system and have just upgraded to glibc
   2.2, but are still using gcc 2.95.2, then you should have read the
   glibc FAQ, specifically 2.34:
2.34.   When compiling C++ programs, I get a compilation error in streambuf.h.

{BH} You are using g++ 2.95.2? After upgrading to glibc 2.2, you need to
apply a patch to the include files in /usr/include/g++, because the fpos_t
type has changed in glibc 2.2.  The patch is at
http://clisp.cons.org/~haible/gccinclude-glibc-2.2-compat.diff


   Note that 2.95.x shipped with the [77]old v2 library which is no
   longer maintained. Also note that gcc 2.95.3 fixes this problem, but
   requires a separate patch for libstdc++-v3.

   concept checks If you see compilation errors containing messages about
   fooConcept and a constraints member function, then most likely you
   have violated one of the requirements for types used during
   instantiation of template containers and functions. For example,
   EqualityComparableConcept appears if your types must be comparable
   with == and you have not provided this capability (a typo, or wrong
   visibility, or you just plain forgot, etc).

   More information, including how to optionally enable/disable the
   checks, is available [78]here.
     _________________________________________________________________

4.5 Aw, that's easy to fix!

   If you have found a bug in the library and you think you have a
   working fix, then send it in! The main GCC site has a page on
   [79]submitting patches that covers the procedure, but for libstdc++
   you should also send the patch to our mailing list in addition to the
   GCC patches mailing list. The libstdc++ [80]contributors' page also
   talks about how to submit patches.

   In addition to the description, the patch, and the ChangeLog entry, it
   is a Good Thing if you can additionally create a small test program to
   test for the presence of the bug that your patch fixes. Bugs have a
   way of being reintroduced; if an old bug creeps back in, it will be
   caught immediately by the [81]testsuite -- but only if such a test
   exists.
     _________________________________________________________________

                               5.0 Miscellaneous

5.1 string::iterator is not char*; vector<T>::iterator is not T*

   If you have code that depends on container<T> iterators being
   implemented as pointer-to-T, your code is broken.

   While there are arguments for iterators to be implemented in that
   manner, A) they aren't very good ones in the long term, and B) they
   were never guaranteed by the Standard anyway. The type-safety achieved
   by making iterators a real class rather than a typedef for T*
   outweighs nearly all opposing arguments.