1<?xml version="1.0" encoding="UTF-8" standalone="no"?> 2<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Design</title><meta name="generator" content="DocBook XSL-NS Stylesheets V1.78.1" /><meta name="keywords" content="C++, library, debug" /><meta name="keywords" content="ISO C++, library" /><meta name="keywords" content="ISO C++, runtime, library" /><link rel="home" href="../index.html" title="The GNU C++ Library" /><link rel="up" href="debug_mode.html" title="Chapter��17.��Debug Mode" /><link rel="prev" href="debug_mode_using.html" title="Using" /><link rel="next" href="parallel_mode.html" title="Chapter��18.��Parallel Mode" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Design</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="debug_mode_using.html">Prev</a>��</td><th width="60%" align="center">Chapter��17.��Debug Mode</th><td width="20%" align="right">��<a accesskey="n" href="parallel_mode.html">Next</a></td></tr></table><hr /></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.ext.debug_mode.design"></a>Design</h2></div></div></div><p> 3 </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="debug_mode.design.goals"></a>Goals</h3></div></div></div><p> 4 </p><p> The libstdc++ debug mode replaces unsafe (but efficient) standard 5 containers and iterators with semantically equivalent safe standard 6 containers and iterators to aid in debugging user programs. The 7 following goals directed the design of the libstdc++ debug mode:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p><span class="emphasis"><em>Correctness</em></span>: the libstdc++ debug mode must not change 8 the semantics of the standard library for all cases specified in 9 the ANSI/ISO C++ standard. The essence of this constraint is that 10 any valid C++ program should behave in the same manner regardless 11 of whether it is compiled with debug mode or release mode. In 12 particular, entities that are defined in namespace std in release 13 mode should remain defined in namespace std in debug mode, so that 14 legal specializations of namespace std entities will remain 15 valid. A program that is not valid C++ (e.g., invokes undefined 16 behavior) is not required to behave similarly, although the debug 17 mode will abort with a diagnostic when it detects undefined 18 behavior.</p></li><li class="listitem"><p><span class="emphasis"><em>Performance</em></span>: the additional of the libstdc++ debug mode 19 must not affect the performance of the library when it is compiled 20 in release mode. Performance of the libstdc++ debug mode is 21 secondary (and, in fact, will be worse than the release 22 mode).</p></li><li class="listitem"><p><span class="emphasis"><em>Usability</em></span>: the libstdc++ debug mode should be easy to 23 use. It should be easily incorporated into the user's development 24 environment (e.g., by requiring only a single new compiler switch) 25 and should produce reasonable diagnostics when it detects a 26 problem with the user program. Usability also involves detection 27 of errors when using the debug mode incorrectly, e.g., by linking 28 a release-compiled object against a debug-compiled object if in 29 fact the resulting program will not run correctly.</p></li><li class="listitem"><p><span class="emphasis"><em>Minimize recompilation</em></span>: While it is expected that 30 users recompile at least part of their program to use debug 31 mode, the amount of recompilation affects the 32 detect-compile-debug turnaround time. This indirectly affects the 33 usefulness of the debug mode, because debugging some applications 34 may require rebuilding a large amount of code, which may not be 35 feasible when the suspect code may be very localized. There are 36 several levels of conformance to this requirement, each with its 37 own usability and implementation characteristics. In general, the 38 higher-numbered conformance levels are more usable (i.e., require 39 less recompilation) but are more complicated to implement than 40 the lower-numbered conformance levels. 41 </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p><span class="emphasis"><em>Full recompilation</em></span>: The user must recompile his or 42 her entire application and all C++ libraries it depends on, 43 including the C++ standard library that ships with the 44 compiler. This must be done even if only a small part of the 45 program can use debugging features.</p></li><li class="listitem"><p><span class="emphasis"><em>Full user recompilation</em></span>: The user must recompile 46 his or her entire application and all C++ libraries it depends 47 on, but not the C++ standard library itself. This must be done 48 even if only a small part of the program can use debugging 49 features. This can be achieved given a full recompilation 50 system by compiling two versions of the standard library when 51 the compiler is installed and linking against the appropriate 52 one, e.g., a multilibs approach.</p></li><li class="listitem"><p><span class="emphasis"><em>Partial recompilation</em></span>: The user must recompile the 53 parts of his or her application and the C++ libraries it 54 depends on that will use the debugging facilities 55 directly. This means that any code that uses the debuggable 56 standard containers would need to be recompiled, but code 57 that does not use them (but may, for instance, use IOStreams) 58 would not have to be recompiled.</p></li><li class="listitem"><p><span class="emphasis"><em>Per-use recompilation</em></span>: The user must recompile the 59 parts of his or her application and the C++ libraries it 60 depends on where debugging should occur, and any other code 61 that interacts with those containers. This means that a set of 62 translation units that accesses a particular standard 63 container instance may either be compiled in release mode (no 64 checking) or debug mode (full checking), but must all be 65 compiled in the same way; a translation unit that does not see 66 that standard container instance need not be recompiled. This 67 also means that a translation unit <span class="emphasis"><em>A</em></span> that contains a 68 particular instantiation 69 (say, <code class="code">std::vector<int></code>) compiled in release 70 mode can be linked against a translation unit <span class="emphasis"><em>B</em></span> that 71 contains the same instantiation compiled in debug mode (a 72 feature not present with partial recompilation). While this 73 behavior is technically a violation of the One Definition 74 Rule, this ability tends to be very important in 75 practice. The libstdc++ debug mode supports this level of 76 recompilation. </p></li><li class="listitem"><p><span class="emphasis"><em>Per-unit recompilation</em></span>: The user must only 77 recompile the translation units where checking should occur, 78 regardless of where debuggable standard containers are 79 used. This has also been dubbed "<code class="code">-g</code> mode", 80 because the <code class="code">-g</code> compiler switch works in this way, 81 emitting debugging information at a per--translation-unit 82 granularity. We believe that this level of recompilation is in 83 fact not possible if we intend to supply safe iterators, leave 84 the program semantics unchanged, and not regress in 85 performance under release mode because we cannot associate 86 extra information with an iterator (to form a safe iterator) 87 without either reserving that space in release mode 88 (performance regression) or allocating extra memory associated 89 with each iterator with <code class="code">new</code> (changes the program 90 semantics).</p></li></ol></div><p> 91 </p></li></ul></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="debug_mode.design.methods"></a>Methods</h3></div></div></div><p> 92 </p><p>This section provides an overall view of the design of the 93 libstdc++ debug mode and details the relationship between design 94 decisions and the stated design goals.</p><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="debug_mode.design.methods.wrappers"></a>The Wrapper Model</h4></div></div></div><p>The libstdc++ debug mode uses a wrapper model where the 95 debugging versions of library components (e.g., iterators and 96 containers) form a layer on top of the release versions of the 97 library components. The debugging components first verify that the 98 operation is correct (aborting with a diagnostic if an error is 99 found) and will then forward to the underlying release-mode 100 container that will perform the actual work. This design decision 101 ensures that we cannot regress release-mode performance (because the 102 release-mode containers are left untouched) and partially 103 enables <a class="link" href="debug_mode_design.html#methods.coexistence.link" title="Link- and run-time coexistence of release- and debug-mode components">mixing debug and 104 release code</a> at link time, although that will not be 105 discussed at this time.</p><p>Two types of wrappers are used in the implementation of the debug 106 mode: container wrappers and iterator wrappers. The two types of 107 wrappers interact to maintain relationships between iterators and 108 their associated containers, which are necessary to detect certain 109 types of standard library usage errors such as dereferencing 110 past-the-end iterators or inserting into a container using an 111 iterator from a different container.</p><div class="section"><div class="titlepage"><div><div><h5 class="title"><a id="debug_mode.design.methods.safe_iter"></a>Safe Iterators</h5></div></div></div><p>Iterator wrappers provide a debugging layer over any iterator that 112 is attached to a particular container, and will manage the 113 information detailing the iterator's state (singular, 114 dereferenceable, etc.) and tracking the container to which the 115 iterator is attached. Because iterators have a well-defined, common 116 interface the iterator wrapper is implemented with the iterator 117 adaptor class template <code class="code">__gnu_debug::_Safe_iterator</code>, 118 which takes two template parameters:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p><code class="code">Iterator</code>: The underlying iterator type, which must 119 be either the <code class="code">iterator</code> or <code class="code">const_iterator</code> 120 typedef from the sequence type this iterator can reference.</p></li><li class="listitem"><p><code class="code">Sequence</code>: The type of sequence that this iterator 121 references. This sequence must be a safe sequence (discussed below) 122 whose <code class="code">iterator</code> or <code class="code">const_iterator</code> typedef 123 is the type of the safe iterator.</p></li></ul></div></div><div class="section"><div class="titlepage"><div><div><h5 class="title"><a id="debug_mode.design.methods.safe_seq"></a>Safe Sequences (Containers)</h5></div></div></div><p>Container wrappers provide a debugging layer over a particular 124 container type. Because containers vary greatly in the member 125 functions they support and the semantics of those member functions 126 (especially in the area of iterator invalidation), container 127 wrappers are tailored to the container they reference, e.g., the 128 debugging version of <code class="code">std::list</code> duplicates the entire 129 interface of <code class="code">std::list</code>, adding additional semantic 130 checks and then forwarding operations to the 131 real <code class="code">std::list</code> (a public base class of the debugging 132 version) as appropriate. However, all safe containers inherit from 133 the class template <code class="code">__gnu_debug::_Safe_sequence</code>, 134 instantiated with the type of the safe container itself (an instance 135 of the curiously recurring template pattern).</p><p>The iterators of a container wrapper will be 136 <a class="link" href="debug_mode_design.html#debug_mode.design.methods.safe_iter" title="Safe Iterators">safe 137 iterators</a> that reference sequences of this type and wrap the 138 iterators provided by the release-mode base class. The debugging 139 container will use only the safe iterators within its own interface 140 (therefore requiring the user to use safe iterators, although this 141 does not change correct user code) and will communicate with the 142 release-mode base class with only the underlying, unsafe, 143 release-mode iterators that the base class exports.</p><p> The debugging version of <code class="code">std::list</code> will have the 144 following basic structure:</p><pre class="programlisting"> 145template<typename _Tp, typename _Allocator = allocator<_Tp> 146 class debug-list : 147 public release-list<_Tp, _Allocator>, 148 public __gnu_debug::_Safe_sequence<debug-list<_Tp, _Allocator> > 149 { 150 typedef release-list<_Tp, _Allocator> _Base; 151 typedef debug-list<_Tp, _Allocator> _Self; 152 153 public: 154 typedef __gnu_debug::_Safe_iterator<typename _Base::iterator, _Self> iterator; 155 typedef __gnu_debug::_Safe_iterator<typename _Base::const_iterator, _Self> const_iterator; 156 157 // duplicate std::list interface with debugging semantics 158 }; 159</pre></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="debug_mode.design.methods.precond"></a>Precondition Checking</h4></div></div></div><p>The debug mode operates primarily by checking the preconditions of 160 all standard library operations that it supports. Preconditions that 161 are always checked (regardless of whether or not we are in debug 162 mode) are checked via the <code class="code">__check_xxx</code> macros defined 163 and documented in the source 164 file <code class="code">include/debug/debug.h</code>. Preconditions that may or 165 may not be checked, depending on the debug-mode 166 macro <code class="code">_GLIBCXX_DEBUG</code>, are checked via 167 the <code class="code">__requires_xxx</code> macros defined and documented in the 168 same source file. Preconditions are validated using any additional 169 information available at run-time, e.g., the containers that are 170 associated with a particular iterator, the position of the iterator 171 within those containers, the distance between two iterators that may 172 form a valid range, etc. In the absence of suitable information, 173 e.g., an input iterator that is not a safe iterator, these 174 precondition checks will silently succeed.</p><p>The majority of precondition checks use the aforementioned macros, 175 which have the secondary benefit of having prewritten debug 176 messages that use information about the current status of the 177 objects involved (e.g., whether an iterator is singular or what 178 sequence it is attached to) along with some static information 179 (e.g., the names of the function parameters corresponding to the 180 objects involved). When not using these macros, the debug mode uses 181 either the debug-mode assertion 182 macro <code class="code">_GLIBCXX_DEBUG_ASSERT</code> , its pedantic 183 cousin <code class="code">_GLIBCXX_DEBUG_PEDASSERT</code>, or the assertion 184 check macro that supports more advance formulation of error 185 messages, <code class="code">_GLIBCXX_DEBUG_VERIFY</code>. These macros are 186 documented more thoroughly in the debug mode source code.</p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="debug_mode.design.methods.coexistence"></a>Release- and debug-mode coexistence</h4></div></div></div><p>The libstdc++ debug mode is the first debug mode we know of that 187 is able to provide the "Per-use recompilation" (4) guarantee, that 188 allows release-compiled and debug-compiled code to be linked and 189 executed together without causing unpredictable behavior. This 190 guarantee minimizes the recompilation that users are required to 191 perform, shortening the detect-compile-debug bug hunting cycle 192 and making the debug mode easier to incorporate into development 193 environments by minimizing dependencies.</p><p>Achieving link- and run-time coexistence is not a trivial 194 implementation task. To achieve this goal we required a small 195 extension to the GNU C++ compiler (since incorporated into the C++11 language specification, described in the GCC Manual for the C++ language as 196 <a class="link" href="http://gcc.gnu.org/onlinedocs/gcc/Namespace-Association.html#Namespace-Association" target="_top">namespace 197 association</a>), and a complex organization of debug- and 198 release-modes. The end result is that we have achieved per-use 199 recompilation but have had to give up some checking of the 200 <code class="code">std::basic_string</code> class template (namely, safe 201 iterators). 202</p><div class="section"><div class="titlepage"><div><div><h5 class="title"><a id="methods.coexistence.compile"></a>Compile-time coexistence of release- and debug-mode components</h5></div></div></div><p>Both the release-mode components and the debug-mode 203 components need to exist within a single translation unit so that 204 the debug versions can wrap the release versions. However, only one 205 of these components should be user-visible at any particular 206 time with the standard name, e.g., <code class="code">std::list</code>. </p><p>In release mode, we define only the release-mode version of the 207 component with its standard name and do not include the debugging 208 component at all. The release mode version is defined within the 209 namespace <code class="code">std</code>. Minus the namespace associations, this 210 method leaves the behavior of release mode completely unchanged from 211 its behavior prior to the introduction of the libstdc++ debug 212 mode. Here's an example of what this ends up looking like, in 213 C++.</p><pre class="programlisting"> 214namespace std 215{ 216 template<typename _Tp, typename _Alloc = allocator<_Tp> > 217 class list 218 { 219 // ... 220 }; 221} // namespace std 222</pre><p>In debug mode we include the release-mode container (which is now 223defined in the namespace <code class="code">__cxx1998</code>) and also the 224debug-mode container. The debug-mode container is defined within the 225namespace <code class="code">__debug</code>, which is associated with namespace 226<code class="code">std</code> via the C++11 namespace association language feature. This 227method allows the debug and release versions of the same component to 228coexist at compile-time and link-time without causing an unreasonable 229maintenance burden, while minimizing confusion. Again, this boils down 230to C++ code as follows:</p><pre class="programlisting"> 231namespace std 232{ 233 namespace __cxx1998 234 { 235 template<typename _Tp, typename _Alloc = allocator<_Tp> > 236 class list 237 { 238 // ... 239 }; 240 } // namespace __gnu_norm 241 242 namespace __debug 243 { 244 template<typename _Tp, typename _Alloc = allocator<_Tp> > 245 class list 246 : public __cxx1998::list<_Tp, _Alloc>, 247 public __gnu_debug::_Safe_sequence<list<_Tp, _Alloc> > 248 { 249 // ... 250 }; 251 } // namespace __cxx1998 252 253 // namespace __debug __attribute__ ((strong)); 254 inline namespace __debug { } 255} 256</pre></div><div class="section"><div class="titlepage"><div><div><h5 class="title"><a id="methods.coexistence.link"></a>Link- and run-time coexistence of release- and 257 debug-mode components</h5></div></div></div><p>Because each component has a distinct and separate release and 258debug implementation, there is no issue with link-time 259coexistence: the separate namespaces result in different mangled 260names, and thus unique linkage.</p><p>However, components that are defined and used within the C++ 261standard library itself face additional constraints. For instance, 262some of the member functions of <code class="code"> std::moneypunct</code> return 263<code class="code">std::basic_string</code>. Normally, this is not a problem, but 264with a mixed mode standard library that could be using either 265debug-mode or release-mode <code class="code"> basic_string</code> objects, things 266get more complicated. As the return value of a function is not 267encoded into the mangled name, there is no way to specify a 268release-mode or a debug-mode string. In practice, this results in 269runtime errors. A simplified example of this problem is as follows. 270</p><p> Take this translation unit, compiled in debug-mode: </p><pre class="programlisting"> 271// -D_GLIBCXX_DEBUG 272#include <string> 273 274std::string test02(); 275 276std::string test01() 277{ 278 return test02(); 279} 280 281int main() 282{ 283 test01(); 284 return 0; 285} 286</pre><p> ... and linked to this translation unit, compiled in release mode:</p><pre class="programlisting"> 287#include <string> 288 289std::string 290test02() 291{ 292 return std::string("toast"); 293} 294</pre><p> For this reason we cannot easily provide safe iterators for 295 the <code class="code">std::basic_string</code> class template, as it is present 296 throughout the C++ standard library. For instance, locale facets 297 define typedefs that include <code class="code">basic_string</code>: in a mixed 298 debug/release program, should that typedef be based on the 299 debug-mode <code class="code">basic_string</code> or the 300 release-mode <code class="code">basic_string</code>? While the answer could be 301 "both", and the difference hidden via renaming a la the 302 debug/release containers, we must note two things about locale 303 facets:</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>They exist as shared state: one can create a facet in one 304 translation unit and access the facet via the same type name in a 305 different translation unit. This means that we cannot have two 306 different versions of locale facets, because the types would not be 307 the same across debug/release-mode translation unit barriers.</p></li><li class="listitem"><p>They have virtual functions returning strings: these functions 308 mangle in the same way regardless of the mangling of their return 309 types (see above), and their precise signatures can be relied upon 310 by users because they may be overridden in derived classes.</p></li></ol></div><p>With the design of libstdc++ debug mode, we cannot effectively hide 311 the differences between debug and release-mode strings from the 312 user. Failure to hide the differences may result in unpredictable 313 behavior, and for this reason we have opted to only 314 perform <code class="code">basic_string</code> changes that do not require ABI 315 changes. The effect on users is expected to be minimal, as there are 316 simple alternatives (e.g., <code class="code">__gnu_debug::basic_string</code>), 317 and the usability benefit we gain from the ability to mix debug- and 318 release-compiled translation units is enormous.</p></div><div class="section"><div class="titlepage"><div><div><h5 class="title"><a id="methods.coexistence.alt"></a>Alternatives for Coexistence</h5></div></div></div><p>The coexistence scheme above was chosen over many alternatives, 319 including language-only solutions and solutions that also required 320 extensions to the C++ front end. The following is a partial list of 321 solutions, with justifications for our rejection of each.</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p><span class="emphasis"><em>Completely separate debug/release libraries</em></span>: This is by 322 far the simplest implementation option, where we do not allow any 323 coexistence of debug- and release-compiled translation units in a 324 program. This solution has an extreme negative affect on usability, 325 because it is quite likely that some libraries an application 326 depends on cannot be recompiled easily. This would not meet 327 our <span class="emphasis"><em>usability</em></span> or <span class="emphasis"><em>minimize recompilation</em></span> criteria 328 well.</p></li><li class="listitem"><p><span class="emphasis"><em>Add a <code class="code">Debug</code> boolean template parameter</em></span>: 329 Partial specialization could be used to select the debug 330 implementation when <code class="code">Debug == true</code>, and the state 331 of <code class="code">_GLIBCXX_DEBUG</code> could decide whether the 332 default <code class="code">Debug</code> argument is <code class="code">true</code> 333 or <code class="code">false</code>. This option would break conformance with the 334 C++ standard in both debug <span class="emphasis"><em>and</em></span> release modes. This would 335 not meet our <span class="emphasis"><em>correctness</em></span> criteria. </p></li><li class="listitem"><p><span class="emphasis"><em>Packaging a debug flag in the allocators</em></span>: We could 336 reuse the <code class="code">Allocator</code> template parameter of containers 337 by adding a sentinel wrapper <code class="code">debug<></code> that 338 signals the user's intention to use debugging, and pick up 339 the <code class="code">debug<></code> allocator wrapper in a partial 340 specialization. However, this has two drawbacks: first, there is a 341 conformance issue because the default allocator would not be the 342 standard-specified <code class="code">std::allocator<T></code>. Secondly 343 (and more importantly), users that specify allocators instead of 344 implicitly using the default allocator would not get debugging 345 containers. Thus this solution fails the <span class="emphasis"><em>correctness</em></span> 346 criteria.</p></li><li class="listitem"><p><span class="emphasis"><em>Define debug containers in another namespace, and employ 347 a <code class="code">using</code> declaration (or directive)</em></span>: This is an 348 enticing option, because it would eliminate the need for 349 the <code class="code">link_name</code> extension by aliasing the 350 templates. However, there is no true template aliasing mechanism 351 in C++, because both <code class="code">using</code> directives and using 352 declarations disallow specialization. This method fails 353 the <span class="emphasis"><em>correctness</em></span> criteria.</p></li><li class="listitem"><p><span class="emphasis"><em> Use implementation-specific properties of anonymous 354 namespaces. </em></span> 355 See <a class="link" href="http://gcc.gnu.org/ml/libstdc++/2003-08/msg00004.html" target="_top"> this post 356 </a> 357 This method fails the <span class="emphasis"><em>correctness</em></span> criteria.</p></li><li class="listitem"><p><span class="emphasis"><em>Extension: allow reopening on namespaces</em></span>: This would 358 allow the debug mode to effectively alias the 359 namespace <code class="code">std</code> to an internal namespace, such 360 as <code class="code">__gnu_std_debug</code>, so that it is completely 361 separate from the release-mode <code class="code">std</code> namespace. While 362 this will solve some renaming problems and ensure that 363 debug- and release-compiled code cannot be mixed unsafely, it ensures that 364 debug- and release-compiled code cannot be mixed at all. For 365 instance, the program would have two <code class="code">std::cout</code> 366 objects! This solution would fails the <span class="emphasis"><em>minimize 367 recompilation</em></span> requirement, because we would only be able to 368 support option (1) or (2).</p></li><li class="listitem"><p><span class="emphasis"><em>Extension: use link name</em></span>: This option involves 369 complicated re-naming between debug-mode and release-mode 370 components at compile time, and then a g++ extension called <span class="emphasis"><em> 371 link name </em></span> to recover the original names at link time. There 372 are two drawbacks to this approach. One, it's very verbose, 373 relying on macro renaming at compile time and several levels of 374 include ordering. Two, ODR issues remained with container member 375 functions taking no arguments in mixed-mode settings resulting in 376 equivalent link names, <code class="code"> vector::push_back() </code> being 377 one example. 378 See <a class="link" href="http://gcc.gnu.org/ml/libstdc++/2003-08/msg00177.html" target="_top">link 379 name</a> </p></li></ul></div><p>Other options may exist for implementing the debug mode, many of 380 which have probably been considered and others that may still be 381 lurking. This list may be expanded over time to include other 382 options that we could have implemented, but in all cases the full 383 ramifications of the approach (as measured against the design goals 384 for a libstdc++ debug mode) should be considered first. The DejaGNU 385 testsuite includes some testcases that check for known problems with 386 some solutions (e.g., the <code class="code">using</code> declaration solution 387 that breaks user specialization), and additional testcases will be 388 added as we are able to identify other typical problem cases. These 389 test cases will serve as a benchmark by which we can compare debug 390 mode implementations.</p></div></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="debug_mode.design.other"></a>Other Implementations</h3></div></div></div><p> 391 </p><p> There are several existing implementations of debug modes for C++ 392 standard library implementations, although none of them directly 393 supports debugging for programs using libstdc++. The existing 394 implementations include:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p><a class="link" href="http://www.cs.sjsu.edu/faculty/horstman/safestl.html" target="_top">SafeSTL</a>: 395 SafeSTL was the original debugging version of the Standard Template 396 Library (STL), implemented by Cay S. Horstmann on top of the 397 Hewlett-Packard STL. Though it inspired much work in this area, it 398 has not been kept up-to-date for use with modern compilers or C++ 399 standard library implementations.</p></li><li class="listitem"><p><a class="link" href="http://www.stlport.org/" target="_top">STLport</a>: STLport is a free 400 implementation of the C++ standard library derived from the <a class="link" href="http://www.sgi.com/tech/stl/" target="_top">SGI implementation</a>, and 401 ported to many other platforms. It includes a debug mode that uses a 402 wrapper model (that in some ways inspired the libstdc++ debug mode 403 design), although at the time of this writing the debug mode is 404 somewhat incomplete and meets only the "Full user recompilation" (2) 405 recompilation guarantee by requiring the user to link against a 406 different library in debug mode vs. release mode.</p></li><li class="listitem"><p>Metrowerks CodeWarrior: The C++ standard library 407 that ships with Metrowerks CodeWarrior includes a debug mode. It is 408 a full debug-mode implementation (including debugging for 409 CodeWarrior extensions) and is easy to use, although it meets only 410 the "Full recompilation" (1) recompilation 411 guarantee.</p></li></ul></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="debug_mode_using.html">Prev</a>��</td><td width="20%" align="center"><a accesskey="u" href="debug_mode.html">Up</a></td><td width="40%" align="right">��<a accesskey="n" href="parallel_mode.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Using��</td><td width="20%" align="center"><a accesskey="h" href="../index.html">Home</a></td><td width="40%" align="right" valign="top">��Chapter��18.��Parallel Mode</td></tr></table></div></body></html>