git
/
gcc
mirror of git://gcc.gnu.org/git/gcc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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 2012-05-03 00:20:38 +01:00
parent d632488ae0
commit 3b2b3556c1
6 changed files with 34 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
libstdc++-v3/ChangeLog
View File

@ -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> 2012-05-02 Benjamin Kosnik <bkoz@redhat.com>
PR libstdc++/44015 PR libstdc++/44015

4
libstdc++-v3/doc/xml/faq.xml
View File

@ -935,8 +935,8 @@
A few people have reported that the standard containers appear A few people have reported that the standard containers appear
to leak memory when tested with memory checkers such as 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>. <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 Under some configurations the library's allocators keep free memory in a
for later reuse, rather than returning it to the OS. Although pool for later reuse, rather than returning it to the OS. Although
this memory is always reachable by the library and is never this memory is always reachable by the library and is never
lost, memory debugging tools can report it as a leak. If you lost, memory debugging tools can report it as a leak. If you
want to test the library for memory leaks please read want to test the library for memory leaks please read

28
libstdc++-v3/doc/xml/manual/allocator.xml
View File

@ -103,7 +103,7 @@
implements the simple operator new and operator delete semantics, implements the simple operator new and operator delete semantics,
while <classname>__gnu_cxx::malloc_allocator</classname> while <classname>__gnu_cxx::malloc_allocator</classname>
implements much the same thing, only with the C language functions 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>
<para> <para>
@ -236,12 +236,12 @@
<para> <para>
In use, <classname>allocator</classname> may allocate and In use, <classname>allocator</classname> may allocate and
deallocate using implementation-specified strategies and deallocate using implementation-specific strategies and
heuristics. Because of this, every call to an allocator object's heuristics. Because of this, a given call to an allocator object's
<function>allocate</function> member function may not actually <function>allocate</function> member function may not actually
call the global operator new. This situation is also duplicated call the global <code>operator new</code> and a given call to
for calls to the <function>deallocate</function> member to the <function>deallocate</function> member function may not
function. call <code>operator delete</code>.
</para> </para>
<para> <para>
@ -250,7 +250,7 @@
<para> <para>
In particular, this can make debugging memory errors more 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>. debug versions of <function>new</function>.
</para> </para>
@ -258,9 +258,9 @@
There are various ways to solve this problem. One would be to use There are various ways to solve this problem. One would be to use
a custom allocator that just called operators a custom allocator that just called operators
<function>new</function> and <function>delete</function> <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.) <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 a non-default allocator. Another option is to force the
default allocator to remove caching and pools, and to directly default allocator to remove caching and pools, and to directly
allocate with every call of <function>allocate</function> and allocate with every call of <function>allocate</function> and
@ -271,8 +271,8 @@
<para> <para>
To globally disable memory caching within the library for the To globally disable memory caching within the library for some of
default allocator, merely set the optional non-default allocators, merely set
<constant>GLIBCXX_FORCE_NEW</constant> (with any value) in the <constant>GLIBCXX_FORCE_NEW</constant> (with any value) in the
system's environment before running the program. If your program system's environment before running the program. If your program
crashes with <constant>GLIBCXX_FORCE_NEW</constant> in the crashes with <constant>GLIBCXX_FORCE_NEW</constant> in the
@ -472,7 +472,8 @@
<para> <para>
A high-performance fixed-size allocator with A high-performance fixed-size allocator with
exponentially-increasing allocations. It has its own 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> </para>
</listitem> </listitem>
@ -483,7 +484,8 @@
<para> <para>
A high-performance allocator that uses a bit-map to keep track A high-performance allocator that uses a bit-map to keep track
of the used and unused memory locations. It has its own 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> </para>
</listitem> </listitem>
</orderedlist> </orderedlist>

4
libstdc++-v3/doc/xml/manual/debug.xml
View File

@ -121,8 +121,8 @@
</para> </para>
<para> <para>
In a nutshell, the default allocator used by <code> In a nutshell, the optional <classname>mt_allocator</classname>
std::allocator</code> is a high-performance pool allocator, and can is a high-performance pool allocator, and can
give the mistaken impression that in a suspect executable, memory is give the mistaken impression that in a suspect executable, memory is
being leaked, when in reality the memory "leak" is a pool being used being leaked, when in reality the memory "leak" is a pool being used
by the library's allocator and is reclaimed after program by the library's allocator and is reclaimed after program

7
libstdc++-v3/doc/xml/manual/evolution.xml
View File

@ -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 <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 <literal>__USE_MALLOC</literal> on the gcc command line would change the
default allocation strategy to instead use <code> malloc</code> and 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 <function>free</function>. For the 3.2 and 3.3 release series the same
<link linkend="manual.intro.using.macros">this page</link> 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. for details.
</para> </para>

11
libstdc++-v3/doc/xml/manual/using.xml
View File

@ -847,17 +847,6 @@ g++ -Winvalid-pch -I. -include stdc++.h -H -g -O2 hello.cc -o test.exe
</para> </para>
</listitem></varlistentry> </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> <varlistentry><term><code>_GLIBCXX_CONCEPT_CHECKS</code></term>
<listitem> <listitem>
<para> <para>