Skip to content

R
riscv-gcc-1
Commit 3b2b3556 by Jonathan Wakely
Options

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
parent d632488a
Showing with 34 additions and 32 deletions
libstdc++-v3/ChangeLog
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
......@@ -21,7 +29,7 @@
* Same. include/std/sstream: Same.
* include/std/streambuf: Same.
* testsuite/23_containers/deque/requirements/dr438/*:
Adjust line numbers.
Adjust line numbers.
* testsuite/23_containers/list/requirements/dr438/*: Same.
* testsuite/23_containers/vector/requirements/dr438/*: Same.
......
libstdc++-v3/doc/xml/faq.xml
......@@ -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
......
libstdc++-v3/doc/xml/manual/allocator.xml
......@@ -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>
......
libstdc++-v3/doc/xml/manual/debug.xml
......@@ -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
......
libstdc++-v3/doc/xml/manual/evolution.xml
......@@ -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>
......
libstdc++-v3/doc/xml/manual/using.xml
......@@ -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>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment