mirror of git://gcc.gnu.org/git/gcc.git
faq.xml: Update outdated allocator documentation.
* doc/xml/faq.xml: Update outdated allocator documentation. * doc/xml/manual/allocator.xml: Likewise. * doc/xml/manual/debug.xml: Likewise. * doc/xml/manual/evolution.xml: Likewise. * doc/xml/manual/using.xml: Likewise. From-SVN: r187068
This commit is contained in:
Jonathan Wakely
parent
d632488ae0
commit
3b2b3556c1
|
|
@ -1,3 +1,11 @@
|
|||
2012-05-03 Jonathan Wakely <jwakely.gcc@gmail.com>
|
||||
|
||||
* doc/xml/faq.xml: Update outdated allocator documentation.
|
||||
* doc/xml/manual/allocator.xml: Likewise.
|
||||
* doc/xml/manual/debug.xml: Likewise.
|
||||
* doc/xml/manual/evolution.xml: Likewise.
|
||||
* doc/xml/manual/using.xml: Likewise.
|
||||
|
||||
2012-05-02 Benjamin Kosnik <bkoz@redhat.com>
|
||||
|
||||
PR libstdc++/44015
|
||||
|
|
|
|||
|
|
@ -935,8 +935,8 @@
|
|||
A few people have reported that the standard containers appear
|
||||
to leak memory when tested with memory checkers such as
|
||||
<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://valgrind.org/">valgrind</link>.
|
||||
The library's default allocators keep free memory in a pool
|
||||
for later reuse, rather than returning it to the OS. Although
|
||||
Under some configurations the library's allocators keep free memory in a
|
||||
pool for later reuse, rather than returning it to the OS. Although
|
||||
this memory is always reachable by the library and is never
|
||||
lost, memory debugging tools can report it as a leak. If you
|
||||
want to test the library for memory leaks please read
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@
|
|||
implements the simple operator new and operator delete semantics,
|
||||
while <classname>__gnu_cxx::malloc_allocator</classname>
|
||||
implements much the same thing, only with the C language functions
|
||||
<function>std::malloc</function> and <function>free</function>.
|
||||
<function>std::malloc</function> and <function>std::free</function>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
@ -236,12 +236,12 @@
|
|||
|
||||
<para>
|
||||
In use, <classname>allocator</classname> may allocate and
|
||||
deallocate using implementation-specified strategies and
|
||||
heuristics. Because of this, every call to an allocator object's
|
||||
deallocate using implementation-specific strategies and
|
||||
heuristics. Because of this, a given call to an allocator object's
|
||||
<function>allocate</function> member function may not actually
|
||||
call the global operator new. This situation is also duplicated
|
||||
for calls to the <function>deallocate</function> member
|
||||
function.
|
||||
call the global <code>operator new</code> and a given call to
|
||||
to the <function>deallocate</function> member function may not
|
||||
call <code>operator delete</code>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
@ -250,7 +250,7 @@
|
|||
|
||||
<para>
|
||||
In particular, this can make debugging memory errors more
|
||||
difficult, especially when using third party tools like valgrind or
|
||||
difficult, especially when using third-party tools like valgrind or
|
||||
debug versions of <function>new</function>.
|
||||
</para>
|
||||
|
||||
|
|
@ -258,9 +258,9 @@
|
|||
There are various ways to solve this problem. One would be to use
|
||||
a custom allocator that just called operators
|
||||
<function>new</function> and <function>delete</function>
|
||||
directly, for every allocation. (See
|
||||
directly, for every allocation. (See the default allocator,
|
||||
<filename>include/ext/new_allocator.h</filename>, for instance.)
|
||||
However, that option would involve changing source code to use
|
||||
However, that option may involve changing source code to use
|
||||
a non-default allocator. Another option is to force the
|
||||
default allocator to remove caching and pools, and to directly
|
||||
allocate with every call of <function>allocate</function> and
|
||||
|
|
@ -271,8 +271,8 @@
|
|||
|
||||
|
||||
<para>
|
||||
To globally disable memory caching within the library for the
|
||||
default allocator, merely set
|
||||
To globally disable memory caching within the library for some of
|
||||
the optional non-default allocators, merely set
|
||||
<constant>GLIBCXX_FORCE_NEW</constant> (with any value) in the
|
||||
system's environment before running the program. If your program
|
||||
crashes with <constant>GLIBCXX_FORCE_NEW</constant> in the
|
||||
|
|
@ -472,7 +472,8 @@
|
|||
<para>
|
||||
A high-performance fixed-size allocator with
|
||||
exponentially-increasing allocations. It has its own
|
||||
documentation, found <link linkend="manual.ext.allocator.mt">here</link>.
|
||||
<link linkend="manual.ext.allocator.mt">chapter</link>
|
||||
in the documentation.
|
||||
</para>
|
||||
</listitem>
|
||||
|
||||
|
|
@ -483,7 +484,8 @@
|
|||
<para>
|
||||
A high-performance allocator that uses a bit-map to keep track
|
||||
of the used and unused memory locations. It has its own
|
||||
documentation, found <link linkend="manual.ext.allocator.bitmap">here</link>.
|
||||
<link linkend="manual.ext.allocator.bitmap">chapter</link>
|
||||
in the documentation.
|
||||
</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
|
|
|
|||
|
|
@ -116,13 +116,13 @@
|
|||
thing of great importance to keep in mind when debugging C++ code
|
||||
that uses <code>new</code> and <code>delete</code>: there are
|
||||
different kinds of allocation schemes that can be used by <code>
|
||||
std::allocator </code>. For implementation details, see the <link linkend="manual.ext.allocator.mt">mt allocator</link> documentation and
|
||||
std::allocator</code>. For implementation details, see the <link linkend="manual.ext.allocator.mt">mt allocator</link> documentation and
|
||||
look specifically for <code>GLIBCXX_FORCE_NEW</code>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In a nutshell, the default allocator used by <code>
|
||||
std::allocator</code> is a high-performance pool allocator, and can
|
||||
In a nutshell, the optional <classname>mt_allocator</classname>
|
||||
is a high-performance pool allocator, and can
|
||||
give the mistaken impression that in a suspect executable, memory is
|
||||
being leaked, when in reality the memory "leak" is a pool being used
|
||||
by the library's allocator and is reclaimed after program
|
||||
|
|
|
|||
|
|
@ -81,8 +81,11 @@ Removal of <filename class="headerfile">ext/tree</filename>, moved to <filename
|
|||
<para> For GCC releases from 2.95 through the 3.1 series, defining
|
||||
<literal>__USE_MALLOC</literal> on the gcc command line would change the
|
||||
default allocation strategy to instead use <code> malloc</code> and
|
||||
<function>free</function>. (This same functionality is now spelled <literal>_GLIBCXX_FORCE_NEW</literal>, see
|
||||
<link linkend="manual.intro.using.macros">this page</link>
|
||||
<function>free</function>. For the 3.2 and 3.3 release series the same
|
||||
functionality was spelled <literal>_GLIBCXX_FORCE_NEW</literal>. From
|
||||
GCC 3.4 onwards the functionality is enabled by setting
|
||||
<literal>GLIBCXX_FORCE_NEW</literal> in the environment, see
|
||||
<link linkend="manual.ext.allocator.mt">the mt allocator chapter</link>
|
||||
for details.
|
||||
</para>
|
||||
|
||||
|
|
|
|||
|
|
@ -847,17 +847,6 @@ g++ -Winvalid-pch -I. -include stdc++.h -H -g -O2 hello.cc -o test.exe
|
|||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
<varlistentry><term><code>_GLIBCXX_FORCE_NEW</code></term>
|
||||
<listitem>
|
||||
<para>
|
||||
Undefined by default. When defined, memory allocation and
|
||||
allocators controlled by libstdc++ call operator new/delete
|
||||
without caching and pooling. Configurable via
|
||||
<code>--enable-libstdcxx-allocator</code>. ABI-changing.
|
||||
</para>
|
||||
</listitem></varlistentry>
|
||||
|
||||
|
||||
<varlistentry><term><code>_GLIBCXX_CONCEPT_CHECKS</code></term>
|
||||
<listitem>
|
||||
<para>
|
||||
|
|
|
|||
Loading…
Reference in New Issue