index.txt

来自「Mac OS X 10.4.9 for x86 Source Code gcc」· 文本 代码 · 共 1,048 行 · 第 1/4 页

   outdated... Also see the RELEASE-NOTES file, which is kept more up to
   date.
     _________________________________________________________________

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 [84]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, [85]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 [86]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 [87]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 [88]here.
   Some of these have resulted in [89]code changes.
     _________________________________________________________________

4.4 Things in libstdc++ that only 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 [90]proposed LWG resolution in 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 [91]sums things up here. The collisions with
   vector/string iterator types have been fixed for 3.1.

  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 [92]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.

   For GCC versions 3.0 and 3.1 the libstdc++-v3 header files are
   installed in ${prefix}/include/g++-v3 (see the 'v'?). Starting with
   version 3.2 the headers are installed in
   ${prefix}/include/c++/${version} as this prevents headers from
   previous versions being found by mistake.

   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 [93]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 [94]here.

   dlopen/dlsym If you are using the C++ library across
   dynamically-loaded objects, make certain that you are passing the
   correct options when compiling and linking:
    // compile your library components
    g++ -fPIC -c a.cc
    g++ -fPIC -c b.cc
    ...
    g++ -fPIC -c z.cc

    // create your library
    g++ -fPIC -shared -rdynamic -o libfoo.so a.o b.o ... z.o

    // link the executable
    g++ -fPIC -rdynamic -o foo ... -L. -lfoo -ldl

   "memory leaks" in containers A few people have reported that the
   standard containers appear to leak memory when tested with memory
   checkers such as [95]valgrind. The library's default allocators keep
   free memory in a pool for later reuse, rather than returning it to the
   OS. Although this memory is always reachable by the library and is
   never lost, memory debugging tools can report it as a leak. If you
   want to test the library for memory leaks please read [96]Tips for
   memory leak hunting first.
     _________________________________________________________________

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
   [97]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++ [98]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 [99]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.

   Code which does assume that a vector iterator i is a pointer can often
   be fixed by changing i in certain expressions to &*i . Future
   revisions of the Standard are expected to bless this usage for
   vector<> (but not for basic_string<>).
     _________________________________________________________________

5.2 What's next after libstdc++-v3?

   Hopefully, not much. The goal of libstdc++-v3 is to produce a
   fully-compliant, fully-portable Standard Library. After that, we're
   mostly done: there won't be any more compliance work to do. However:
    1. The ISO Committee will meet periodically to review Defect Reports
       in the C++ Standard. Undoubtedly some of these will result in
       changes to the Standard, which will be reflected in patches to
       libstdc++. Some of that is already happening, see 4.2. Some of
       those changes are being predicted by the library maintainers, and
       we add code to the library based on what the current proposed
       resolution specifies. Those additions are listed in [100]the
       extensions page.
    2. Performance tuning. Lots of performance tuning. This too is
       already underway for post-3.0 releases, starting with memory
       expansion in container classes and buffer usage in synchronized
       stream objects.
    3. An ABI for libstdc++ is being developed, so that multiple
       binary-incompatible copies of the library can be replaced with a
       single backwards-compatible library, like libgcc_s.so is.
    4. The current libstdc++ contains extensions to the Library which
       must be explicitly requested by client code (for example, the hash
       tables from SGI). Other extensions may be added to libstdc++-v3 if
       they seem to be "standard" enough. (For example, the "long long"
       type from C99.) Bugfixes and rewrites (to improve or fix thread
       safety, for instance) will of course be a continuing task.

   [101]This question about the next libstdc++ prompted some brief but
   interesting [102]speculation.
     _________________________________________________________________

5.3 What about the STL from SGI?

   The [103]STL from SGI, version 3.3, was the final merge of the STL
   codebase. The code in libstdc++ contains many fixes and changes, and
   the SGI code is no longer under active development. We expect that no
   future merges will take place.

   In particular, string is not from SGI and makes no use of their "rope"
   class (which is included as an optional extension), nor is valarray
   and some others. Classes like vector<> are, however we have made
   significant changes to them since then.

   The FAQ for SGI's STL (one jump off of their main page) is recommended
   reading.
     _________________________________________________________________

5.4 Extensions and Backward Compatibility

   Headers in the ext and backward subdirectories should be referred to
   by their relative paths:
      #include <ext/hash_map>

   rather than using -I or other options. This is more portable and
   forward-compatible. (The situation is the same as that of other
   headers whose directories are not searched directly, e.g.,
   <sys/stat.h>, <X11/Xlib.h>.

   The extensions are no longer in the global or std namespaces, instead
   they are declared in the __gnu_cxx namespace. For maximum portability,
   consider defining a namespace alias to use to talk about extensions,
   e.g.:
      #ifdef __GNUC__
      #if __GNUC__ < 3
        #include <hash_map.h>
        namespace Sgi { using ::hash_map; }; // inherit globals
      #else
        #include <ext/hash_map>
        #if __GNUC_MINOR__ == 0
          namespace Sgi = std;               // GCC 3.0
        #else
          namespace Sgi = ::__gnu_cxx;       // GCC 3.1 and later
        #endif
      #endif
      #else      // ...  there are other compilers, right?
        namespace Sgi = std;
      #endif