index.txt

linux下编程用 编译软件

   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. Update: for GCC 4.0 we implemented the resolution of
   [91]DR #409 and open() now calls clear() on success!

   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 [92]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 [93]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 [94]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 [95]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 [96]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 [97]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
   [98]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++ [99]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 [100]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 [101]4.3. 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 [102]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.
    5. There is an effort underway to add significant extensions to the
       standard library specification. The latest version of this effort
       is described in [103]The C++ Library Technical Report 1. See
       [104]5.5.

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

5.3 What about the STL from SGI?

   The [107]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>.

   At this time most of the features of the SGI STL extension have been
   replaced by standardized libraries. In particular, the unordered_map
   and unordered_set containers of TR1 are suitable replacement for the
   non-standard hash_map and hash_set containers in the SGI STL. See
   [108]5.5 for more details.

   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

      Sgi::hash_map<int,int> my_map;

   This is a bit cleaner than defining typedefs for all the
   instantiations you might need.

   Note: explicit template specializations must be declared in the same
   namespace as the original template. This means you cannot use a
   namespace alias when declaring an explicit specialization.

   Extensions to the library have [109]their own page.
     _________________________________________________________________

5.5 Does libstdc++ support TR1?

   The C++ Standard Library Technical Report adds many new features to
   the library. The latest version of this effort is described in
   [110]Technical Report 1.

   libstdc++ strives to implement all of TR1. An [111]overview of the
   implementation status is available.

   Briefly, the features of TR1 and the current status are:

   Unordered containers - Complete - The unordered_set, unordered_map,
   unordered_multiset, and unordered_multimap containers are hashed
   versions of the map, set, multimap, and multiset containers
   respectively. These classes are suitable replacements for the SGI STL
   hash_map and hash_set extensions.

   Reference-counted smart pointers - Complete - The shared_ptr and
   weak_ptr allow several object to know about a pointer and whether it
   is valid. When the last reference to the pointer is destroyed the
   pointer is freed.

   Type traits - Complete - The type_traits class gives templates the
   ability to probe information about the input type and enable