# doxygroups.cc

    00001 /*
    00002    Copyright (C) 2001, 2002 Free Software Foundation, Inc.
    00003    See license.html for license.
    00004
    00005    This just provides documentation for stuff that doesn't need to be in the
    00006    source headers themselves.  It is a ".cc" file for the sole cheesy reason
    00007    that it triggers many different text editors into doing Nice Things when
    00008    typing comments.  However, it is mentioned nowhere except the *cfg.in files.
    00009
    00010    Some actual code (declarations) is exposed here, but no compiler ever
    00011    sees it.  The decls must be visible to doxygen, and sometimes their real
    00012    declarations are not visible, or not visible in a way we want.
    00013
    00014    Pieces separated by '// //' lines will usually not be presented to the
    00015    user on the same page.
    00016 */
    00017
    00018 // // // // // // // // // // // // // // // // // // // // // // // //
    00019 /** @namespace std
    00020  *  @brief Everything defined by the ISO C++ Standard is within namespace std.
    00021 */
    00022 /** @namespace __gnu_cxx
    00023  *  @brief This namespace serves two purposes.
    00024  *
    00025  *  This namespace is used for two things:
    00026  *  -  sequestering internal (implementation-only) names away from the
    00027  *     global namespace; these are details of the implementation and should
    00028  *     not be touched by users
    00029  *  -  GNU extensions for public use
    00030  *
    00031  *  This is still fluid and changing rapidly.  Currently the rule is:  if an
    00032  *  entitity is found in the user-level documentation, it falls into the
    00033  *  second category.
    00034 */
    00035
    00036 // // // // // // // // // // // // // // // // // // // // // // // //
    00037 /** @addtogroup SGIextensions STL extensions from SGI
    00038 Because libstdc++-v3 based its implementation of the STL subsections of
    00039 the library on the SGI 3.3 implementation, we inherited their extensions
    00040 as well.
    00041
    00042 They are additionally documented in the
    00043 <a href="http://gcc.gnu.org/onlinedocs/libstdc++/documentation.html">
    00044 online documentation</a>, a copy of which is also shipped with the
    00045 library source code (in .../docs/html/documentation.html).  You can also
    00046 read the documentation <a href="http://www.sgi.com/tech/stl/">on SGI's
    00047 site</a>, which is still running even though the code is not maintained.
    00048
    00049 <strong>NB</strong> that the following notes are pulled from various
    00050 comments all over the place, so they may seem stilted.
    00051 <hr>
    00052 */
    00053
    00054 // // // // // // // // // // // // // // // // // // // // // // // //
    00055 // This is standalone because, unlike the functor introduction, there is no
    00056 // single header file which serves as a base "all containers must include
    00057 // this header".  We do some quoting of 14882 here.
    00058 /** @addtogroup Containers Containers
    00059 Containers are collections of objects.
    00060
    00061 A container may hold any type which meets certain requirements, but the type
    00062 of contained object is chosen at compile time, and all objects in a given
    00063 container must be of the same type.  (Polymorphism is possible by declaring a
    00064 container of pointers to a base class and then populating it with pointers to
    00065 instances of derived classes.  Variant value types such as the @c any class
    00066 from <a href="http://www.boost.org/">Boost</a> can also be used.
    00067
    00068 All contained types must be @c Assignable and @c CopyConstructible.
    00069 Specific containers may place additional requirements on the types of
    00070 their contained objects.
    00071
    00072 Containers manage memory allocation and deallocation themselves when
    00073 storing your objects.  The objects are destroyed when the container is
    00074 itself destroyed.  Note that if you are storing pointers in a container,
    00075 @c delete is @e not automatically called on the pointers before destroying them.
    00076
    00077 All containers must meet certain requirements, summarized in
    00078 <a href="tables.html">tables</a>.
    00079
    00080 The standard containers are further refined into
    00081 @link Sequences Sequences@endlink and
    00082 @link Assoc_containers Associative Containers@endlink.
    00083 */
    00084
    00085 /** @addtogroup Sequences Sequences
    00086 Sequences arrange a collection of objects into a strictly linear order.
    00087
    00088 The differences between sequences are usually due to one or both of the
    00089 following:
    00090   - memory management
    00091   - algorithmic complexity
    00092
    00093 As an example of the first case, @c vector is required to use a contiguous
    00094 memory layout, while other sequences such as @c deque are not.
    00095
    00096 The prime reason for choosing one sequence over another should be based on
    00097 the second category of differences, algorithmic complexity.  For example, if
    00098 you need to perform many inserts and removals from the middle of a sequence,
    00099 @c list would be ideal.  But if you need to perform constant-time access to
    00100 random elements of the sequence, then @c list should not be used.
    00101
    00102 All sequences must meet certain requirements, summarized in
    00103 <a href="tables.html">tables</a>.
    00104 */
    00105
    00106 /** @addtogroup Assoc_containers Associative Containers
    00107 Associative containers allow fast retrieval of data based on keys.
    00108
    00109 Each container type is parameterized on a @c Key type, and an ordering
    00110 relation used to sort the elements of the container.
    00111
    00112 There should be more text here.
    00113
    00114 All associative containers must meet certain requirements, summarized in
    00115 <a href="tables.html">tables</a>.
    00116 */
    00117
    00118 // // // // // // // // // // // // // // // // // // // // // // // //
    00119 /** @namespace abi
    00120  *  @brief The cross-vendor C++ Application Binary Interface.
    00121  *
    00122  *  A brief overview of an ABI is given in the libstdc++-v3 FAQ, question
    00123  *  5.8 (you may have a copy of the FAQ locally, or you can view the online
    00124  *  version at http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#5_8).
    00125  *
    00126  *  GCC subscribes to a relatively-new cross-vendor ABI for C++, sometimes
    00127  *  called the IA64 ABI because it happens to be the native ABI for that
    00128  *  platform.  It is summarized at http://www.codesourcery.com/cxx-abi/
    00129  *  along with the current specification.
    00130  *
    00131  *  For users of GCC 3.x, entry points are available in <cxxabi.h>, which notes,
    00132  *  <em>"It is not normally necessary for user programs to include this header,
    00133  *  or use the entry points directly.  However, this header is available
    00134  *  should that be needed."</em>
    00135 */
    00136
    00137 namespace abi {
    00138 /**
    00139 @brief New ABI-mandated entry point in the C++ runtime library for demangling.
    00140
    00141 @param mangled_name A NUL-terminated character string containing the name
    00142                     to be demangled.
    00143
    00144 @param output_buffer A region of memory, allocated with malloc, of
    00145                      @a *length bytes, into which the demangled name
    00146                      is stored.  If @a output_buffer is not long enough,
    00147                      it is expanded using realloc.  @a output_buffer may
    00148                      instead be NULL; in that case, the demangled name is
    00149                      placed in a region of memory allocated with malloc.
    00150
    00151 @param length If @a length is non-NULL, the length of the buffer containing
    00152               the demangled name is placed in @a *length.
    00153
    00154 @param status @a *status is set to one of the following values:
    00155               -   0: The demangling operation succeeded.
    00156               -  -1: A memory allocation failiure occurred.
    00157               -  -2: @a mangled_name is not a valid name under the C++ ABI
    00158                      mangling rules.
    00159               -  -3: One of the arguments is invalid.
    00160
    00161 @return A pointer to the start of the NUL-terminated demangled name, or NULL
    00162         if the demangling fails.  The caller is responsible for deallocating
    00163         this memory using @c free.
    00164
    00165
    00166 The demagling is performed using the C++ ABI mangling rules, with
    00167 GNU extensions.  For example, this function is used
    00168 in __gnu_cxx::__verbose_terminate_handler.  See
    00169 http://gcc.gnu.org/onlinedocs/libstdc++/18_support/howto.html#5 for other
    00170 examples of use.
    00171
    00172 @note The same demangling functionality is available via libiberty
    00173 (@c <libiberty/demangle.h> and @c libiberty.a) in GCC 3.1 and later, but that
    00174 requires explicit installation (@c --enable-install-libiberty) and uses a
    00175 different API, although the ABI is unchanged.
    00176 */
    00177 char* __cxa_demangle (const char* mangled_name, char* output_buffer,
    00178                       size_t* length, int* status);
    00179 } // namespace abi
    00180
    00181 // // // // // // // // // // // // // // // // // // // // // // // //
    00182 /** @addtogroup binarysearch Binary search algorithms
    00183 These algorithms are variations of a classic binary search.  They all assume
    00184 that the sequence being searched is already sorted.
    00185
    00186 The number of comparisons will be logarithmic (and as few as possible).
    00187 The number of steps through the sequence will be logarithmic for
    00188 random-access iterators (e.g., pointers), and linear otherwise.
    00189
    00190 The LWG has passed Defect Report 270, which notes:  <em>The proposed
    00191 resolution reinterprets binary search. Instead of thinking about searching
    00192 for a value in a sorted range, we view that as an important special
    00193 case of a more general algorithm: searching for the partition point in a
    00194 partitioned range.  We also add a guarantee that the old wording did not:
    00195 we ensure that the upper bound is no earlier than the lower bound, that
    00196 the pair returned by equal_range is a valid range, and that the first part
    00197 of that pair is the lower bound.</em>
    00198
    00199 The actual effect of the first sentence is that a comparison functor
    00200 passed by the user doesn't necessarily need to induce a strict weak ordering
    00201 relation.  Rather, it partitions the range.
    00202 */
    00203
    00204 // // // // // // // // // // // // // // // // // // // // // // // //
    00205 /** @addtogroup setoperations Set operation algorithms
    00206 These algorithms are common set operations performed on sequences that are
    00207 already sorted.
    00208
    00209 The number of comparisons will be linear.
    00210 */
    00211
    00212 // // // // // // // // // // // // // // // // // // // // // // // //
    00213
    00214 // // // // // // // // // // // // // // // // // // // // // // // //
    00215 /* * @addtogroup groupname description of group
    00216 placeholder text
    00217 */
    00218
    00219 // // // // // // // // // // // // // // // // // // // // // // // //
    00220
    00221 // vim:et:noai:
    00222