libstdc++-v3/docs/html/debug_mode.html

   1 <?xml version="1.0" encoding="ISO-8859-1"?>
   2 <!DOCTYPE html
   3           PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   4           "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   5
   6 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   7 <head>
   8    <meta name="AUTHOR" content="dgregor@apple.com (Doug Gregor)" />
   9    <meta name="KEYWORDS" content="libstdc++, libstdc++-v3, GCC, g++, debug" />
  10    <meta name="DESCRIPTION" content="Design of the libstdc++ debug mode." />
  11    <meta name="GENERATOR" content="vi and eight fingers" />
  12    <title>Design of the libstdc++ debug mode</title>
  13 <link rel="StyleSheet" href="lib3styles.css" />
  14 </head>
  15 <body>
  16
  17 <h1 class="centered"><a name="top">Design of the libstdc++ debug mode</a></h1>
  18
  19 <p class="fineprint"><em>
  20    The latest version of this document is always available at
  21    <a href="http://gcc.gnu.org/onlinedocs/libstdc++/debug_mode.html">
  22    http://gcc.gnu.org/onlinedocs/libstdc++/debug_mode.html</a>.
  23 </em></p>
  24
  25 <p><em>
  26    To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++-v3 homepage</a>.
  27 </em></p>
  28
  29
  30 <!-- ####################################################### -->
  31
  32 <hr />
  33 <h1>Debug mode design</h1>
  34 <p> The libstdc++ debug mode replaces unsafe (but efficient) standard
  35   containers and iterators with semantically equivalent safe standard
  36   containers and iterators to aid in debugging user programs. The
  37   following goals directed the design of the libstdc++ debug mode:</p>
  38
  39   <ul>
  40
  41     <li><b>Correctness</b>: the libstdc++ debug mode must not change
  42     the semantics of the standard library for all cases specified in
  43     the ANSI/ISO C++ standard. The essence of this constraint is that
  44     any valid C++ program should behave in the same manner regardless
  45     of whether it is compiled with debug mode or release mode. In
  46     particular, entities that are defined in namespace std in release
  47     mode should remain defined in namespace std in debug mode, so that
  48     legal specializations of namespace std entities will remain
  49     valid. A program that is not valid C++ (e.g., invokes undefined
  50     behavior) is not required to behave similarly, although the debug
  51     mode will abort with a diagnostic when it detects undefined
  52     behavior.</li>
  53
  54     <li><b>Performance</b>: the additional of the libstdc++ debug mode
  55     must not affect the performance of the library when it is compiled
  56     in release mode. Performance of the libstdc++ debug mode is
  57     secondary (and, in fact, will be worse than the release
  58     mode).</li>
  59
  60     <li><b>Usability</b>: the libstdc++ debug mode should be easy to
  61     use. It should be easily incorporated into the user's development
  62     environment (e.g., by requiring only a single new compiler switch)
  63     and should produce reasonable diagnostics when it detects a
  64     problem with the user program. Usability also involves detection
  65     of errors when using the debug mode incorrectly, e.g., by linking
  66     a release-compiled object against a debug-compiled object if in
  67     fact the resulting program will not run correctly.</li>
  68
  69     <li><b>Minimize recompilation</b>: While it is expected that
  70     users recompile at least part of their program to use debug
  71     mode, the amount of recompilation affects the
  72     detect-compile-debug turnaround time. This indirectly affects the
  73     usefulness of the debug mode, because debugging some applications
  74     may require rebuilding a large amount of code, which may not be
  75     feasible when the suspect code may be very localized. There are
  76     several levels of conformance to this requirement, each with its
  77     own usability and implementation characteristics. In general, the
  78     higher-numbered conformance levels are more usable (i.e., require
  79     less recompilation) but are more complicated to implement than
  80     the lower-numbered conformance levels.
  81       <ol>
  82         <li><b>Full recompilation</b>: The user must recompile his or
  83         her entire application and all C++ libraries it depends on,
  84         including the C++ standard library that ships with the
  85         compiler. This must be done even if only a small part of the
  86         program can use debugging features.</li>
  87
  88         <li><b>Full user recompilation</b>: The user must recompile
  89         his or her entire application and all C++ libraries it depends
  90         on, but not the C++ standard library itself. This must be done
  91         even if only a small part of the program can use debugging
  92         features. This can be achieved given a full recompilation
  93         system by compiling two versions of the standard library when
  94         the compiler is installed and linking against the appropriate
  95         one, e.g., a multilibs approach.</li>
  96
  97         <li><b>Partial recompilation</b>: The user must recompile the
  98         parts of his or her application and the C++ libraries it
  99         depends on that will use the debugging facilities
 100         directly. This means that any code that uses the debuggable
 101         standard containers would need to be recompiled, but code
 102         that does not use them (but may, for instance, use IOStreams)
 103         would not have to be recompiled.</li>
 104
 105         <li><b>Per-use recompilation</b>: The user must recompile the
 106         parts of his or her application and the C++ libraries it
 107         depends on where debugging should occur, and any other code
 108         that interacts with those containers. This means that a set of
 109         translation units that accesses a particular standard
 110         container instance may either be compiled in release mode (no
 111         checking) or debug mode (full checking), but must all be
 112         compiled in the same way; a translation unit that does not see
 113         that standard container instance need not be recompiled. This
 114         also means that a translation unit <em>A</em> that contains a
 115         particular instantiation
 116         (say, <code>std::vector&lt;int&gt;</code>) compiled in release
 117         mode can be linked against a translation unit <em>B</em> that
 118         contains the same instantiation compiled in debug mode (a
 119         feature not present with partial recompilation). While this
 120         behavior is technically a violation of the One Definition
 121         Rule, this ability tends to be very important in
 122         practice. The libstdc++ debug mode supports this level of
 123         recompilation. </li>
 124
 125         <li><b>Per-unit recompilation</b>: The user must only
 126         recompile the translation units where checking should occur,
 127         regardless of where debuggable standard containers are
 128         used. This has also been dubbed "<code>-g</code> mode",
 129         because the <code>-g</code> compiler switch works in this way,
 130         emitting debugging information at a per--translation-unit
 131         granularity. We believe that this level of recompilation is in
 132         fact not possible if we intend to supply safe iterators, leave
 133         the program semantics unchanged, and not regress in
 134         performance under release mode because we cannot associate
 135         extra information with an iterator (to form a safe iterator)
 136         without either reserving that space in release mode
 137         (performance regression) or allocating extra memory associated
 138         with each iterator with <code>new</code> (changes the program
 139         semantics).</li>
 140       </ol>
 141     </li>
 142   </ul>
 143
 144 <h2><a name="other">Other implementations</a></h2>
 145 <p> There are several existing implementations of debug modes for C++
 146   standard library implementations, although none of them directly
 147   supports debugging for programs using libstdc++. The existing
 148   implementations include:</p>
 149 <ul>
 150   <li><a
 151   href="http://www.mathcs.sjsu.edu/faculty/horstman/safestl.html">SafeSTL</a>:
 152   SafeSTL was the original debugging version of the Standard Template
 153   Library (STL), implemented by Cay S. Horstmann on top of the
 154   Hewlett-Packard STL. Though it inspired much work in this area, it
 155   has not been kept up-to-date for use with modern compilers or C++
 156   standard library implementations.</li>
 157
 158   <li><a href="http://www.stlport.org/">STLport</a>: STLport is a free
 159   implementation of the C++ standard library derived from the <a
 160   href="http://www.sgi.com/tech/stl/">SGI implementation</a>, and
 161   ported to many other platforms. It includes a debug mode that uses a
 162   wrapper model (that in some way inspired the libstdc++ debug mode
 163   design), although at the time of this writing the debug mode is
 164   somewhat incomplete and meets only the "Full user recompilation" (2)
 165   recompilation guarantee by requiring the user to link against a
 166   different library in debug mode vs. release mode.</li>
 167
 168   <li><a href="http://www.metrowerks.com/mw/default.htm">Metrowerks
 169   CodeWarrior</a>: The C++ standard library that ships with Metrowerks
 170   CodeWarrior includes a debug mode. It is a full debug-mode
 171   implementation (including debugging for CodeWarrior extensions) and
 172   is easy to use, although it meets only the "Full recompilation" (1)
 173   recompilation guarantee.</li>
 174 </ul>
 175
 176 <h2><a name="design">Debug mode design methodology</a></h2>
 177 <p>This section provides an overall view of the design of the
 178   libstdc++ debug mode and details the relationship between design
 179   decisions and the stated design goals.</p>
 180
 181 <h3><a name="wrappers">The wrapper model</a></h3>
 182 <p>The libstdc++ debug mode uses a wrapper model where the debugging
 183   versions of library components (e.g., iterators and containers) form
 184   a layer on top of the release versions of the library
 185   components. The debugging components first verify that the operation
 186   is correct (aborting with a diagnostic if an error is found) and
 187   will then forward to the underlying release-mode container that will
 188   perform the actual work. This design decision ensures that we cannot
 189   regress release-mode performance (because the release-mode
 190   containers are left untouched) and partially enables <a
 191   href="#mixing">mixing debug and release code</a> at link time,
 192   although that will not be discussed at this time.</p>
 193
 194 <p>Two types of wrappers are used in the implementation of the debug
 195   mode: container wrappers and iterator wrappers. The two types of
 196   wrappers interact to maintain relationships between iterators and
 197   their associated containers, which are necessary to detect certain
 198   types of standard library usage errors such as dereferencing
 199   past-the-end iterators or inserting into a container using an
 200   iterator from a different container.</p>
 201
 202 <h4><a name="safe_iterator">Safe iterators</a></h4>
 203 <p>Iterator wrappers provide a debugging layer over any iterator that
 204   is attached to a particular container, and will manage the
 205   information detailing the iterator's state (singular,
 206   dereferenceable, etc.) and tracking the container to which the
 207   iterator is attached. Because iterators have a well-defined, common
 208   interface the iterator wrapper is implemented with the iterator
 209   adaptor class template <code>__gnu_debug::_Safe_iterator</code>,
 210   which takes two template parameters:</p>
 211
 212 <ul>
 213   <li><code>Iterator</code>: The underlying iterator type, which must
 214     be either the <code>iterator</code> or <code>const_iterator</code>
 215     typedef from the sequence type this iterator can reference.</li>
 216
 217   <li><code>Sequence</code>: The type of sequence that this iterator
 218   references. This sequence must be a safe sequence (discussed below)
 219   whose <code>iterator</code> or <code>const_iterator</code> typedef
 220   is the type of the safe iterator.</li>
 221 </ul>
 222
 223 <h4><a name="safe_sequence">Safe sequences (containers)</a></h4>
 224 <p>Container wrappers provide a debugging layer over a particular
 225   container type. Because containers vary greatly in the member
 226   functions they support and the semantics of those member functions
 227   (especially in the area of iterator invalidation), container
 228   wrappers are tailored to the container they reference, e.g., the
 229   debugging version of <code>std::list</code> duplicates the entire
 230   interface of <code>std::list</code>, adding additional semantic
 231   checks and then forwarding operations to the
 232   real <code>std::list</code> (a public base class of the debugging
 233   version) as appropriate. However, all safe containers inherit from
 234   the class template <code>__gnu_debug::_Safe_sequence</code>,
 235   instantiated with the type of the safe container itself (an instance
 236   of the curiously recurring template pattern).</p>
 237
 238 <p>The iterators of a container wrapper will be
 239   <a href="#safe_iterator">safe iterators</a> that reference sequences
 240   of this type and wrap the iterators provided by the release-mode
 241   base class. The debugging container will use only the safe
 242   iterators within its own interface (therefore requiring the user to
 243   use safe iterators, although this does not change correct user
 244   code) and will communicate with the release-mode base class with
 245   only the underlying, unsafe, release-mode iterators that the base
 246   class exports.</p>
 247
 248 <p> The debugging version of <code>std::list</code> will have the
 249   following basic structure:</p>
 250
 251 <pre>
 252 template&lt;typename _Tp, typename _Allocator = std::allocator&lt;_Tp&gt;
 253   class debug-list :
 254     public release-list&lt;_Tp, _Allocator&gt;,
 255     public __gnu_debug::_Safe_sequence&lt;debug-list&lt;_Tp, _Allocator&gt; &gt;
 256   {
 257     typedef release-list&lt;_Tp, _Allocator&gt; _Base;
 258     typedef debug-list&lt;_Tp, _Allocator&gt;   _Self;
 259
 260   public:
 261     typedef __gnu_debug::_Safe_iterator&lt;typename _Base::iterator, _Self&gt;       iterator;
 262     typedef __gnu_debug::_Safe_iterator&lt;typename _Base::const_iterator, _Self&gt; const_iterator;
 263
 264     // duplicate std::list interface with debugging semantics
 265   };
 266 </pre>
 267
 268 <h3><a name="precondition">Precondition checking</a></h3>
 269 <p>The debug mode operates primarily by checking the preconditions of
 270   all standard library operations that it supports. Preconditions that
 271   are always checked (regardless of whether or not we are in debug
 272   mode) are checked via the <code>__check_xxx</code> macros defined
 273   and documented in the source
 274   file <code>include/debug/debug.h</code>. Preconditions that may or
 275   may not be checked, depending on the debug-mode
 276   macro <code>_GLIBCXX_DEBUG</code>, are checked via
 277   the <code>__requires_xxx</code> macros defined and documented in the
 278   same source file. Preconditions are validated using any additional
 279   information available at run-time, e.g., the containers that are
 280   associated with a particular iterator, the position of the iterator
 281   within those containers, the distance between two iterators that may
 282   form a valid range, etc. In the absence of suitable information,
 283   e.g., an input iterator that is not a safe iterator, these
 284   precondition checks will silently succeed.</p>
 285
 286 <p>The majority of precondition checks use the aforementioned macros,
 287   which have the secondary benefit of having prewritten debug
 288   messages that use information about the current status of the
 289   objects involved (e.g., whether an iterator is singular or what
 290   sequence it is attached to) along with some static information
 291   (e.g., the names of the function parameters corresponding to the
 292   objects involved). When not using these macros, the debug mode uses
 293   either the debug-mode assertion
 294   macro <code>_GLIBCXX_DEBUG_ASSERT</code> , its pedantic
 295   cousin <code>_GLIBCXX_DEBUG_PEDASSERT</code>, or the assertion
 296   check macro that supports more advance formulation of error
 297   messages, <code>_GLIBCXX_DEBUG_VERIFY</code>. These macros are
 298   documented more thoroughly in the debug mode source code.</p>
 299
 300 <h3><a name="coexistence">Release- and debug-mode coexistence</a></h3>
 301 <p>The libstdc++ debug mode is the first debug mode we know of that
 302   is able to provide the "Per-use recompilation" (4) guarantee, that
 303   allows release-compiled and debug-compiled code to be linked and
 304   executed together without causing unpredictable behavior. This
 305   guarantee minimizes the recompilation that users are required to
 306   perform, shortening the detect-compile-debug bughunting cycle
 307   and making the debug mode easier to incorporate into development
 308   environments by minimizing dependencies.</p>
 309
 310 <p>Achieving link- and run-time coexistence is not a trivial
 311   implementation task. To achieve this goal we required a small
 312   extension to the GNU C++ compiler (described in the section on
 313   <a href="#mixing">link- and run-time coexistence</a>) and complex
 314   organization of debug- and release-modes. The end result is that we
 315   have achieved per-use recompilation but have had to give up some
 316   checking of the <code>std::basic_string</code> class template
 317   (namely, safe iterators).
 318
 319 <h4><a name="compile_coexistence">Compile-time coexistence of release- and
 320     debug-mode components</a></h4>
 321 <p>Both the release-mode components and the debug-mode
 322   components need to exist within a single translation unit so that
 323   the debug versions can wrap the release versions. However, only one
 324   of these components should be user-visible at any particular
 325   time with the standard name, e.g., <code>std::list</code>. In
 326   release mode, we define only the release-mode version of the
 327   component with its standard name and do not include the debugging
 328   component at all (except, perhaps, in <code>__gnu_debug</code>, if
 329   requested via the separate debugging headers). This method leaves the
 330   behavior of release mode completely unchanged from its behavior
 331   prior to the introduction of the libstdc++ debug mode.</p>
 332
 333 <p>In debug mode we include the release-mode container into its
 334   natural namespace but perform renaming to an implementation-defined
 335   name using preprocessor macros. Thus the
 336   release-mode <code>std::list</code> will be renamed
 337   to <code>std::_Release_list</code> during debug mode, and we will
 338   automatically include the debugging version with the
 339   name <code>std::list</code> for users to reference. This method
 340   allows the debug- and release-mode versions of the same component to
 341   coexist at compile-time without causing an unreasonable maintenance
 342   burden.</p>
 343
 344 <h4><a name="mixing">Link- and run-time coexistence of release- and
 345     debug-mode components</a></h4>
 346 <p>There is a problem with the simple compile-time coexistence
 347   mechanism: if a user compiles some modules with release mode and
 348   some modules with debug mode, the debuggable components will differ
 349   in different translation units, violating the C++ One Definition
 350   Rule (ODR). This violation will likely be detected at link time,
 351   because the sizes of debug-mode containers will differ from the
 352   sizes of release-mode containers, although in some cases (such as
 353   dynamic linking) the error may be detected much later (or not at
 354   all!).</p>
 355
 356 <p>Unfortunately, it is not possible to avoid violating the ODR with
 357   most debug mode designs (see the section on <a
 358   href="#coexistence_alt">alternatives for coexistence</a>), so the
 359   philosophy of the libstdc++ debug mode is to acknowledge that there
 360   is an unavoidable ODR violation in this case but to ensure that the
 361   ODR violation does not affect execution. To accomplish this, the
 362   libstdc++ debug mode uses the aforementioned preprocessor renaming
 363   scheme but includes an additional renaming scheme that happens at
 364   compile-time that essentially reverses the preprocessor
 365   renaming <em>from the linker's point of view</em>. Thus, in debug
 366   mode, the release-mode <code>list</code> container is
 367   named <code>std::_Release_list</code> but will be mangled with the
 368   name <code>std::list</code> (as it was in release mode). Similarly,
 369   the debug-mode <code>list</code> is named <code>std::list</code>
 370   (in debug mode) but will be mangled
 371   as <code>std::_Debug_list</code>. Thus the
 372   release-mode <code>list</code> always compiles down to code that
 373   uses the name <code>std::list</code>, and the
 374   debug-mode <code>list</code> always compiles down to code that uses
 375   the name <code>std::_Debug_list</code>, independent of the use of
 376   debug mode. This has several positive effects:</p>
 377
 378 <ul>
 379   <li>No linking conflicts between debug/release objects: because the
 380   names of the debug- and release-mode containers are different in the
 381   compiled object files, there are no link-time conflicts between the
 382   two.</li>
 383
 384   <li>Release-mode code is shared: the release-mode code can be shared
 385   within a program, even with it is compiled partly in release-mode
 386   and partly in debug-mode, because the release-mode code is unchanged
 387   in name and function. This can decrease the size of mixed
 388   debug/release binaries.</li>
 389
 390   <li>Able to catch <em>most</em> invalid debug/release combinations:
 391   because the names of debug- and release-mode containers are
 392   different in the compiled object files, if a debug/release
 393   interaction cannot occur (e.g., because a container a translation
 394   unit compiled in debug mode is passed to a routine in a translation
 395   unit compiled in release mode) the result will be an undefined
 396   symbol at link time. The undefined symbol occurs because the mangled
 397   name of the definition will contain the release-mode container type
 398   and the mangled name of the reference will contain the debug-mode
 399   container type. However, we cannot detect these collisions if the
 400   only use of the container is in the return type, because the return
 401   type is not part of the mangled name of a function.</li>
 402 </ul>
 403
 404 <p>The new <code>link_name</code> class attribute facilities
 405   renaming. It may be attached to any class type (or any class
 406   template) to override the name of the class used for name
 407   mangling. For instance, a class named <code>bar</code> would
 408   generally mangle as <code>3bar</code>; if the class has
 409   a <code>link_name</code> attribute that specifies the string
 410   "wibble", then it would mangle as <code>6wibble</code>.</p>
 411
 412 <p>Note that although we have hidden the ODR violation, it still
 413   exists. For this reason we cannot easily provide safe iterators for
 414   the <code>std::basic_string</code> class template, as it is present
 415   throughout the C++ standard library. For instance, locale facets
 416   define typedefs that include <code>basic_string</code>: in a mixed
 417   debug/release program, should that typedef be based on the
 418   debug-mode <code>basic_string</code> or the
 419   release-mode <code>basic_string</code>? While the answer could be
 420   "both", and the difference hidden via renaming a la the
 421   debug/release containers, we must note two things about locale
 422   facets:</p>
 423
 424 <ol>
 425   <li>They exist as shared state: one can create a facet in one
 426   translation unit and access the facet via the same type name in a
 427   different translation unit. This means that we cannot have two
 428   different versions of locale facets, because the types would not be
 429   the same across debug/release-mode translation unit barriers.</li>
 430
 431   <li>They have virtual functions returning strings: these functions
 432   mangle in the same way regardless of the mangling of their return
 433   types (see above), and their precise signatures can be relied upon
 434   by users because they may be overridden in derived classes.
 435 </ol>
 436
 437 <p>With the design of libstdc++ debug mode, we cannot effectively hide
 438   the differences between debug and release-mode strings from the
 439   user. Failure to hide the differences may result in unpredictable
 440   behavior, and for this reason we have opted to only
 441   perform <code>basic_string</code> changes that do not require ABI
 442   changes. The effect on users is expected to be minimal, as there are
 443   simple alternatives (e.g., <code>__gnu_debug::basic_string</code>),
 444   and the usability benefit we gain from the ability to mix debug- and
 445   release-compiled translation units is enormous.</p>
 446
 447 <h4><a name="coexistence_alt">Alternatives for Coexistence</a></h4>
 448 <p>The coexistence scheme was chosen over many alternatives,
 449   including language-only solutions and solutions that also required
 450   extensions to the C++ front end. The following is a partial list of
 451   solutions, with justifications for our rejection of each.</p>
 452
 453 <ul>
 454   <li><em>Completely separate debug/release libraries</em>: This is by
 455   far the simplest implementation option, where we do not allow any
 456   coexistence of debug- and release-compiled translation units in a
 457   program. This solution has an extreme negative affect on usability,
 458   because it is quite likely that some libraries an application
 459   depends on cannot be recompiled easily. This would not meet
 460   our <b>usability</b> or <b>minimize recompilation</b> criteria
 461   well.</li>
 462
 463   <li><em>Add a <code>Debug</code> boolean template parameter</em>:
 464   Partial specialization could be used to select the debug
 465   implementation when <code>Debug == true</code>, and the state
 466   of <code>_GLIBCXX_DEBUG</code> could decide whether the
 467   default <code>Debug</code> argument is <code>true</code>
 468   or <code>false</code>. This option would break conformance with the
 469   C++ standard in both debug <em>and</em> release modes. This would
 470   not meet our <b>correctness</b> criteria. </li>
 471
 472   <li><em>Packaging a debug flag in the allocators</em>: We could
 473     reuse the <code>Allocator</code> template parameter of containers
 474     by adding a sentinel wrapper <code>debug&lt;&gt;</code> that
 475     signals the user's intention to use debugging, and pick up
 476     the <code>debug&lr;&gt;</code> allocator wrapper in a partial
 477     specialization. However, this has two drawbacks: first, there is a
 478     conformance issue because the default allocator would not be the
 479     standard-specified <code>std::allocator&lt;T&gt;</code>. Secondly
 480     (and more importantly), users that specify allocators instead of
 481     implicitly using the default allocator would not get debugging
 482     containers. Thus this solution fails the <b>correctness</b>
 483     criteria.</li>
 484
 485   <li><em>Define debug containers in another namespace, and employ
 486       a <code>using</code> declaration (or directive)</em>: This is an
 487       enticing option, because it would eliminate the need for
 488       the <code>link_name</code> extension by aliasing the
 489       templates. However, there is no true template aliasing mechanism
 490       is C++, because both <code>using</code> directives and using
 491       declarations disallow specialization. This method fails
 492       the <b>correctness</b> criteria.</li>
 493
 494   <li><em>Extension: allow template aliasing/renaming</em>: This is
 495     the runner-up to the <code>link_name</code> solution, eliminated
 496     only because it requires more extensive compiler changes
 497     than <code>link_name</code>. In this model, we would define the
 498     debug containers in a different namespace
 499     (e.g., <code>__gnu_debug</code>) and then import them (e.g., with
 500     an extended <code>using</code> declaration that aliases templates,
 501     such as that of <a
 502     href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1449.pdf">template
 503     aliases</a> proposal). This solution is workable, and in fact
 504     would be desirable in the long run, but requires a sizeable change
 505     to the C++ compiler front-end that is not within the scope of
 506     this project.</li>
 507
 508   <li><em>Extension: allow reopening on namespaces</em>: This would
 509     allow the debug mode to effectively alias the
 510     namespace <code>std</code> to an internal namespace, such
 511     as <code>__gnu_std_debug</code>, so that it is completely
 512     separate from the release-mode <code>std</code> namespace. While
 513     this will solve some renaming problems and ensure that
 514     debug- and release-compiled code cannot be mixed unsafely, it ensures that
 515     debug- and release-compiled code cannot be mixed at all. For
 516     instance, the program would have two <code>std::cout</code>
 517     objects! This solution would fails the <b>minimize
 518     recompilation</b> requirement, because we would only be able to
 519     support option (1) or (2).</li>
 520   </li>
 521 </ul>
 522
 523 <p>Other options may exist for implementing the debug mode, many of
 524   which have probably been considered and others that may still be
 525   lurking. This list may be expanded over time to include other
 526   options that we could have implemented, but in all cases the full
 527   ramifications of the approach (as measured against the design goals
 528   for a libstdc++ debug mode) should be considered first. The DejaGNU
 529   testsuite includes some testcases that check for known problems with
 530   some solutions (e.g., the <code>using</code> declaration solution
 531   that breaks user specialization), and additional testcases will be
 532   added as we are able to identify other typical problem cases. These
 533   test cases will serve as a benchmark by which we can compare debug
 534   mode implementations.</p>
 535
 536 <!-- ####################################################### -->
 537
 538 <hr />
 539 <p class="fineprint"><em>
 540 See <a href="17_intro/license.html">license.html</a> for copying conditions.
 541 Comments and suggestions are welcome, and may be sent to
 542 <a href="mailto:libstdc++@gcc.gnu.org">the libstdc++ mailing list</a>.
 543 </em></p>
 544
 545
 546 </body>
 547 </html>