index.txt

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

      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 [104]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 [105]17 (library introduction), [106]23 (containers), and
   [107]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 [108]here. (And if you've already registered with them, clicking
   this link will take you to directly to the place where you can
   [109]buy the standard on-line.

   Who is your country's member body? Visit the [110]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.
     _________________________________________________________________

5.9 How do I make std::vector<T>::capacity() == std::vector<T>::size()?

   The standard idiom for deallocating a std::vector<T>'s unused memory
   is to create a temporary copy of the vector and swap their contents,
   e.g. for std::vector<T> v
     std::vector<T>(v).swap(v);


   The copy will take O(n) time and the swap is constant time.

   See [111]Shrink-to-fit strings for a similar solution for strings.
     _________________________________________________________________

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

References

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