index.txt

测试手写程序

   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 [82]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++ will eventually be 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.

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

5.3 What about the STL from SGI?

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

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

5.4 Extensions and Backward Compatibility

   Although you can specify -I options to make the preprocessor search
   the g++-v3/ext and /backward directories, it is better to refer to
   files there by their path, as in:
       #include <ext/hash_map>


   Extensions to the library have [86]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?

   When the system's libc is itself thread-safe, a non-generic
   implementation of atomicity.h exists for the architecture, and gcc
   itself reports a thread model other than single; libstdc++-v3 strives
   to be thread-safe. 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. 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 [87]17 (library introduction), [88]23 (containers), and
   [89]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 [90]here. (And if you've already registered with them, clicking
   this link will take you to directly to the place where you can [91]buy
   the standard on-line.

   Who is your country's member body? Visit the [92]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 [93]license.html for copying conditions. Comments and suggestions
   are welcome, and may be sent to [94]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#4_0
  26. ../faq/index.html#4_1
  27. ../faq/index.html#4_2
  28. ../faq/index.html#4_3
  29. ../faq/index.html#4_4
  30. ../faq/index.html#4_4_iostreamclear
  31. ../faq/index.html#4_4_Weff
  32. ../faq/index.html#4_4_rel_ops
  33. ../faq/index.html#4_4_interface
  34. ../faq/index.html#4_4_glibc
  35. ../faq/index.html#4_4_checks
  36. ../faq/index.html#4_5
  37. ../faq/index.html#5_0
  38. ../faq/index.html#5_1
  39. ../faq/index.html#5_2
  40. ../faq/index.html#5_3
  41. ../faq/index.html#5_4
  42. ../faq/index.html#5_5
  43. ../faq/index.html#5_6
  44. ../faq/index.html#5_7
  45. ../faq/index.html#5_8
  46. http://gcc.gnu.org/libstdc++/download.html
  47. ../faq/index.html#4_4_interface
  48. ../17_intro/DESIGN
  49. http://gcc.gnu.org/
  50. http://gcc.gnu.org/gcc-2.95/buildstat.html
  51. http://gcc.gnu.org/libstdc++/
  52. http://gcc.gnu.org/libstdc++/download.html
  53. http://gcc.gnu.org/libstdc++/
  54. ../17_intro/contribute.html
  55. http://www.boost.org/
  56. http://gcc.gnu.org/fom_serv/cache/33.html
  57. mailto:[e-mail]
  58. mailto:[e-mail]
  59. mailto:[e-mail]
  60. ../17_intro/license.html
  61. ../documentation.html
  62. ../17_intro/RELEASE-NOTES
  63. http://www.gnu.org/software/cvs/cvs.html
  64. http://www.cvshome.org/
  65. ../18_support/howto.html
  66. http://gcc.gnu.org/install/configure.html
  67. http://gcc.gnu.org/bugs.html
  68. http://gcc.gnu.org/ml/libstdc++/2002-02/msg00034.html
  69. http://gcc.gnu.org/ml/libstdc++/1998/msg00006.html
  70. http://www.cantrip.org/draft-bugs.txt
  71. http://anubis.dkuug.dk/jtc1/sc22/wg21/
  72. ../faq/index.html#5_2
  73. ../ext/howto.html#5
  74. http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html
  75. http://gcc.gnu.org/gnatswrite.html
  76. http://gcc.gnu.org/ml/gcc/2000-10/msg00732.html
  77. ../faq/index.html#4_4_interface
  78. ../19_diagnostics/howto.html#3
  79. http://gcc.gnu.org/contribute.html
  80. ../17_intro/contribute.html
  81. ../faq/index.html#2_4
  82. ../ext/howto.html#5
  83. http://gcc.gnu.org/ml/libstdc++/1999/msg00080.html
  84. http://gcc.gnu.org/ml/libstdc++/1999/msg00084.html
  85. http://www.sgi.com/Technology/STL/
  86. ../ext/howto.html
  87. ../17_intro/howto.html#3
  88. ../23_containers/howto.html#3
  89. ../27_io/howto.html#9
  90. http://www.ansi.org/
  91. http://webstore.ansi.org/ansidocstore/product.asp?sku=ISO%2FIEC+14882%2D1998
  92. http://www.iso.ch/
  93. ../17_intro/license.html
  94. mailto:[e-mail]