index.txt

俄罗斯高人Mamaich的Pocket gcc编译器（运行在PocketPC上）的全部源代码。

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

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

5.3 What about the STL from SGI?

   The [100]STL from SGI, version 3.3, was the most recent merge of the
   STL codebase. The code in libstdc++ contains many fixes and changes,
   and it is very likely that 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

      Sgi::hash_map<int,int> my_map;

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

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

5.5 [removed]

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

5.6 Is libstdc++-v3 thread-safe?

   libstdc++-v3 strives to be thread-safe when all of the following
   conditions are met:
     * The system's libc is itself thread-safe,
     * gcc -v reports a thread model other than 'single',
     * [pre-3.3 only] a non-generic implementation of atomicity.h exists
       for the architecture in question.

   The user-code must guard against concurrent method calls which may
   access any particular library object's state. Typically, the
   application programmer may infer what object locks must be held based
   on the objects referenced in a method call. Without getting into great
   detail, here is an example which requires user-level locks:
     library_class_a shared_object_a;

     thread_main () {
       library_class_b *object_b = new library_class_b;
       shared_object_a.add_b (object_b);   // must hold lock for shared_object_
a
       shared_object_a.mutate ();          // must hold lock for shared_object_
a
     }

     // Multiple copies of thread_main() are started in independent threads.

   Under the assumption that object_a and object_b are never exposed to
   another thread, here is an example that should not require any
   user-level locks:
     thread_main () {
       library_class_a object_a;
       library_class_b *object_b = new library_class_b;
       object_a.add_b (object_b);
       object_a.mutate ();
     }

   All library objects are safe to use in a multithreaded program as long
   as each thread carefully locks out access by any other thread while it
   uses any object visible to another thread, i.e., treat library objects
   like any other shared resource. In general, this requirement includes
   both read and write access to objects; unless otherwise documented as
   safe, do not assume that two threads may access a shared standard
   library object at the same time.

   See chapters [102]17 (library introduction), [103]23 (containers), and
   [104]27 (I/O) for more information.
     _________________________________________________________________

5.7 How do I get a copy of the ISO C++ Standard?

   Copies of the full ISO 14882 standard are available on line via the
   ISO mirror site for committee members. Non-members, or those who have
   not paid for the privilege of sitting on the committee and sustained
   their two-meeting commitment for voting rights, may get a copy of the
   standard from their respective national standards organization. In the
   USA, this national standards organization is ANSI and their website is
   right [105]here. (And if you've already registered with them, clicking
   this link will take you to directly to the place where you can
   [106]buy the standard on-line.

   Who is your country's member body? Visit the [107]ISO homepage and
   find out!
     _________________________________________________________________

5.8 What's an ABI and why is it so messy?

   "ABI" stands for "Application Binary Interface." Conventionally, it
   refers to a great mass of details about how arguments are arranged on
   the call stack and/or in registers, and how various types are arranged
   and padded in structs. A single CPU design may suffer multiple ABIs
   designed by different development tool vendors who made different
   choices, or even by the same vendor for different target applications
   or compiler versions. In ideal circumstances the CPU designer presents
   one ABI and all the OSes and compilers use it. In practice every ABI
   omits details that compiler implementers (consciously or accidentally)
   must choose for themselves.

   That ABI definition suffices for compilers to generate code so a
   program can interact safely with an OS and its lowest-level libraries.
   Users usually want an ABI to encompass more detail, allowing libraries
   built with different compilers (or different releases of the same
   compiler!) to be linked together. For C++, this includes many more
   details than for C, and CPU designers (for good reasons elaborated
   below) have not stepped up to publish C++ ABIs. The details include
   virtual function implementation, struct inheritance layout, name
   mangling, and exception handling. Such an ABI has been defined for GNU
   C++, and is immediately useful for embedded work relying only on a
   "free-standing implementation" that doesn't include (much of) the
   standard library. It is a good basis for the work to come.

   A useful C++ ABI must also incorporate many details of the standard
   library implementation. For a C ABI, the layouts of a few structs
   (such as FILE, stat, jmpbuf, and the like) and a few macros suffice.
   For C++, the details include the complete set of names of functions
   and types used, the offsets of class members and virtual functions,
   and the actual definitions of all inlines. C++ exposes many more
   library details to the caller than C does. It makes defining a
   complete ABI a much bigger undertaking, and requires not just
   documenting library implementation details, but carefully designing
   those details so that future bug fixes and optimizations don't force
   breaking the ABI.

   There are ways to help isolate library implementation details from the
   ABI, but they trade off against speed. Library details used in inner
   loops (e.g., getchar) must be exposed and frozen for all time, but
   many others may reasonably be kept hidden from user code, so they may
   later be changed. Deciding which, and implementing the decisions, must
   happen before you can reasonably document a candidate C++ ABI that
   encompasses the standard library.
     _________________________________________________________________

   See [108]license.html for copying conditions. Comments and suggestions
   are welcome, and may be sent to [109]the libstdc++ mailing list. 

References

   1. http://gcc.gnu.org/onlinedocs/libstdc++/faq/
   2. http://gcc.gnu.org/onlinedocs/libstdc++/documentation.html
   3. http://gcc.gnu.org/libstdc++/
   4. ../faq/index.html#1_0
   5. ../faq/index.html#1_1
   6. ../faq/index.html#1_2
   7. ../faq/index.html#1_3
   8. ../faq/index.html#1_4
   9. ../faq/index.html#1_5
  10. ../faq/index.html#1_6
  11. ../faq/index.html#1_7
  12. ../faq/index.html#1_8
  13. ../faq/index.html#1_9
  14. ../faq/index.html#2_0
  15. ../faq/index.html#2_1
  16. ../faq/index.html#2_2
  17. ../faq/index.html#2_3
  18. ../faq/index.html#2_4
  19. ../faq/index.html#2_5
  20. ../faq/index.html#3_0
  21. ../faq/index.html#3_1
  22. ../faq/index.html#3_2
  23. ../faq/index.html#3_3
  24. ../faq/index.html#3_4
  25. ../faq/index.html#3_5
  26. ../faq/index.html#3_6
  27. ../faq/index.html#3_7
  28. ../faq/index.html#3_8
  29. ../faq/index.html#3_9
  30. ../faq/index.html#3_10
  31. ../faq/index.html#4_0
  32. ../faq/index.html#4_1
  33. ../faq/index.html#4_2
  34. ../faq/index.html#4_3
  35. ../faq/index.html#4_4
  36. ../faq/index.html#4_4_iostreamclear
  37. ../faq/index.html#4_4_Weff
  38. ../faq/index.html#4_4_rel_ops
  39. ../faq/index.html#4_4_interface
  40. ../faq/index.html#4_4_glibc
  41. ../faq/index.html#4_4_checks
  42. ../faq/index.html#4_4_dlsym
  43. ../faq/index.html#4_4_leak
  44. ../faq/index.html#4_5
  45. ../faq/index.html#5_0
  46. ../faq/index.html#5_1
  47. ../faq/index.html#5_2
  48. ../faq/index.html#5_3
  49. ../faq/index.html#5_4
  50. ../faq/index.html#5_5
  51. ../faq/index.html#5_6
  52. ../faq/index.html#5_7
  53. ../faq/index.html#5_8
  54. http://gcc.gnu.org/libstdc++/index.html#download
  55. ../faq/index.html#1_4
  56. ../faq/index.html#4_4_interface
  57. ../17_intro/DESIGN
  58. http://gcc.gnu.org/
  59. http://gcc.gnu.org/gcc-3.0/buildstat.html
  60. http://gcc.gnu.org/libstdc++/
  61. http://gcc.gnu.org/libstdc++/
  62. http://gcc.gnu.org/releases.html
  63. ../17_intro/contribute.html
  64. http://www.boost.org/
  65. http://gcc.gnu.org/extensions.html
  66. mailto:[e-mail]
  67. mailto:[e-mail]
  68. mailto:[e-mail]
  69. ../17_intro/license.html
  70. ../documentation.html
  71. ../17_intro/RELEASE-NOTES
  72. http://www.gnu.org/software/cvs/cvs.html
  73. http://www.cvshome.org/
  74. http://gcc.gnu.org/install/test.html
  75. ../18_support/howto.html
  76. http://gcc.gnu.org/cgi-bin/htsearch?method=and&format=builtin-long&sort=score&words=_XOPEN_SOURCE+Solaris
  77. http://gcc.gnu.org/ml/gcc/2002-03/msg00817.html
  78. http://gcc.gnu.org/ml/libstdc++/2003-02/subjects.html#00286
  79. http://gcc.gnu.org/install/configure.html
  80. http://gcc.gnu.org/install/
  81. http://gcc.gnu.org/bugs.html
  82. http://gcc.gnu.org/ml/libstdc++/2002-02/msg00034.html
  83. http://gcc.gnu.org/ml/libstdc++/1998/msg00006.html
  84. http://www.cantrip.org/draft-bugs.txt
  85. http://anubis.dkuug.dk/jtc1/sc22/wg21/
  86. ../faq/index.html#5_2
  87. ../ext/howto.html#5
  88. http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html
  89. http://gcc.gnu.org/gnatswrite.html
  90. ../faq/index.html#4_4_interface
  91. ../19_diagnostics/howto.html#3
  92. http://developer.kde.org/~sewardj/
  93. ../debug.html#mem
  94. http://gcc.gnu.org/contribute.html
  95. ../17_intro/contribute.html
  96. ../faq/index.html#2_4
  97. ../ext/howto.html#5
  98. http://gcc.gnu.org/ml/libstdc++/1999/msg00080.html
  99. http://gcc.gnu.org/ml/libstdc++/1999/msg00084.html
 100. http://www.sgi.com/Technology/STL/
 101. ../ext/howto.html
 102. ../17_intro/howto.html#3
 103. ../23_containers/howto.html#3
 104. ../27_io/howto.html#9
 105. http://www.ansi.org/
 106. http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%2D1998
 107. http://www.iso.ch/
 108. ../17_intro/license.html
 109. mailto:[e-mail]