Lines Matching full:release
45 of whether it is compiled with debug mode or release mode. In
46 particular, entities that are defined in namespace std in release
56 in release mode. Performance of the libstdc++ debug mode is
57 secondary (and, in fact, will be worse than the release
66 a release-compiled object against a debug-compiled object if in
110 container instance may either be compiled in release mode (no
116 (say, <code>std::vector<int></code>) compiled in release
134 performance under release mode because we cannot associate
136 without either reserving that space in release mode
166 different library in debug mode vs. release mode.</li>
184 a layer on top of the release versions of the library
187 will then forward to the underlying release-mode container that will
189 regress release-mode performance (because the release-mode
191 href="#mixing">mixing debug and release code</a> at link time,
240 of this type and wrap the iterators provided by the release-mode
244 code) and will communicate with the release-mode base class with
245 only the underlying, unsafe, release-mode iterators that the base
254 public release-list<_Tp, _Allocator>,
257 typedef release-list<_Tp, _Allocator> _Base;
300 <h3><a name="coexistence">Release- and debug-mode coexistence</a></h3>
303 allows release-compiled and debug-compiled code to be linked and
316 release-modes. The end result is that we have achieved per-use
322 <h4><a name="compile_coexistence">Compile-time coexistence of release- and
324 <p>Both the release-mode components and the debug-mode
326 the debug versions can wrap the release versions. However, only one
330 <p>In release mode, we define only the release-mode version of the
332 component at all. The release mode version is defined within the
334 method leaves the behavior of release mode completely unchanged from
350 <p>In debug mode we include the release-mode container (which is now
355 method allows the debug and release versions of the same component to
387 <h4><a name="mixing">Link- and run-time coexistence of release- and
390 <p>Because each component has a distinct and separate release and
400 debug-mode or release-mode <code> basic_string</code> objects, things
403 release-mode or a debug-mode string. In practice, this results in
426 <p> ... and linked to this translation unit, compiled in release mode:</p>
442 debug/release program, should that typedef be based on the
444 release-mode <code>basic_string</code>? While the answer could be
446 debug/release containers, we must note two things about locale
454 the same across debug/release-mode translation unit barriers.</li>
463 the differences between debug and release-mode strings from the
470 release-compiled translation units is enormous.</p>
479 <li><em>Completely separate debug/release libraries</em>: This is by
481 coexistence of debug- and release-compiled translation units in a
494 C++ standard in both debug <em>and</em> release modes. This would
530 separate from the release-mode <code>std</code> namespace. While
532 debug- and release-compiled code cannot be mixed unsafely, it ensures that
533 debug- and release-compiled code cannot be mixed at all. For
540 complicated re-naming between debug-mode and release-mode