Skip to content

R
riscv-gcc-1
Commit 7145a3dd by Phil Edwards
Options

explanations.html: New section, empty for now. 

2001-11-27  Phil Edwards  <pme@gcc.gnu.org>

	* docs/html/explanations.html:  New section, empty for now.
	* docs/html/17_intro/howto.html:  Cleanup.  Move unrelated link...
	* docs/html/23_containers/howto.html:  ...to here.  Break up and
	rewrap threading discussion to emphasize warning.  Move malloc text...
	* docs/html/ext/howto.html:  ...to here.  New section.  Describe
	allocators and __USE_MALLOC effects.
	* docs/html/ext/sgiexts.html:  Mention their code.

From-SVN: r47391
parent 8a63621f
Showing with 236 additions and 24 deletions
libstdc++-v3/ChangeLog
2001-11-27 Phil Edwards <pme@gcc.gnu.org>
* docs/html/explanations.html: New section, empty for now.
* docs/html/17_intro/howto.html: Cleanup. Move unrelated link...
* docs/html/23_containers/howto.html: ...to here. Break up and
rewrap threading discussion to emphasize warning. Move malloc text...
* docs/html/ext/howto.html: ...to here. New section. Describe
allocators and __USE_MALLOC effects.
* docs/html/ext/sgiexts.html: Mention their code.
2001-11-24 Joseph S. Myers <jsm28@cam.ac.uk>
* docs/doxygen/maint.cfg.in, docs/doxygen/user.cfg.in,
......
libstdc++-v3/docs/html/17_intro/howto.html
......@@ -74,7 +74,7 @@
</p>
<p>All normal disclaimers aside, multithreaded C++ application are
only supported when libstdc++ and all user code was built with
compilers which report (via <em>gcc/g++ -v</em>) the same thread
compilers which report (via <code> gcc/g++ -v </code>) the same thread
model and that model is not <em>single</em>. As long as your
final application is actually single-threaded, then it should be
safe to mix user code built with a thread model of
......@@ -89,7 +89,7 @@
</p>
<p>When you link a multithreaded application, you will probably
need to add a library or flag to g++. This is a very
non-standardized area of gcc across ports. Some ports support a
non-standardized area of GCC across ports. Some ports support a
special flag (the spelling isn't even standardized yet) to add
all required macros to a compilation (if any such flags are
required then you must provide the flag for all compilations not
......@@ -135,9 +135,6 @@
This message</a> inspired a recent updating of issues with threading
and the SGI STL library. It also contains some example
POSIX-multithreaded STL code.
<li><a href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00136.html">
Here</a> is an early analysis of why __USE_MALLOC should be disabled
for the 3.0 release of libstdc++.</a>
</ul>
(A large selection of links to older messages has been removed; many
of the messages from 1999 were lost in a disk crash, and the few
......
libstdc++-v3/docs/html/23_containers/howto.html
......@@ -244,14 +244,22 @@
</p>
<p>The STL implementation is currently configured to use the
high-speed caching memory allocator. If you absolutely think
you must change this on a global basis for your platform to
better support multi-threading, then please consult all
commentary in include/bits/c++config. (Explicit warning since
so many people post after getting confused while attempting
this:) Adding -D__USE_MALLOC on the command line is not a good
idea. Related to threading or otherwise, the current
recommendation is that users not add any macro defines on the
command line to enable features out of libstdc++-v3. There is
you must change this on a global basis for your platform to better
support multi-threading, then please consult all commentary in
include/bits/stl_alloc.h and the allocators link below.
<blockquote>
<p>(Explicit warning since so many people get confused while
attempting this:)
</p>
<p><strong>Adding -D__USE_MALLOC on the command
line is almost certainly a bad idea.</strong> Memory efficiency is
almost guaranteed to suffer as a result; this is
<a href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00136.html">why
we disabled it for 3.0 in the first place</a>.
</p>
<p>Related to threading or otherwise, the current recommendation is
that users not add any macro defines on the command line to remove or
otherwise disable features of libstdc++-v3. There is
no condition under which it will help you without causing other
issues to perhaps raise up (possible linkage/ABI problems). In
particular, __USE_MALLOC should only be added to a libstdc++-v3
......@@ -259,22 +267,22 @@
action is cautioned against), and the entire library should be
rebuilt. If you do not, then you might be violating the
one-definition rule of C/C++ and you might cause yourself untold
problems. If you find any platform where gcc reports a
threading model other than single and where libstdc++-v3 builds
problems.
</p>
</blockquote>
If you find any platform where gcc reports a
threading model other than single, and where libstdc++-v3 builds
a buggy container allocator when used with threads unless you
define __USE_MALLOC, we want to hear about it ASAP. In the
past, correctness was the main reason people were led to believe
that they should define __USE_MALLOC when using threads.
</p>
<p>There is a better way (not standardized yet): It is possible to
<p>There is a better way (not standardized yet): It is possible to
force the malloc-based allocator on a per-case-basis for some
application code. The library team generally believes that this
is a better way to tune an application for high-speed using this
implementation of the STL. Here is one possible example
displaying the forcing of the malloc-based allocator over the
typically higher-speed default allocator:
<pre>
std::list &lt;my_type, std::__malloc_alloc_template&lt;0&gt; &gt; my_malloc_based_list;</pre>
implementation of the STL. There is
<a href="../ext/howto.html#3">more information on allocators here</a>.
</p>
<p>Return <a href="#top">to top of page</a> or
<a href="../faq/index.html">to the FAQ</a>.
......
libstdc++-v3/docs/html/explanations.html
......@@ -61,6 +61,15 @@ design</a></h1>
</p>
<hr>
<a name="alloc"><h3>Internal Allocators</h3></a>
<p>
</p>
<p>Return <a href="#top">to the top of the page</a> or
<a href="http://gcc.gnu.org/libstdc++/">to the homepage</a>.
</p>
<!-- ####################################################### -->
<hr>
......
libstdc++-v3/docs/html/ext/sgiexts.html
......@@ -25,7 +25,7 @@ libstdc++-v3</a></h1>
for a description). Not every chapter may have extensions, and the
extensions may come and go. Also, this page is incomplete because the
author is pressed for time. Check back often; the latest change was on
$Date: 2001/10/11 18:41:47 $ (UTC).
$Date: 2001/11/23 16:29:01 $ (UTC).
</p>
<p>Descriptions range from the scanty to the verbose. You should also check
......@@ -60,6 +60,9 @@ libstdc++-v3</a></h1>
<li>mem_fun adaptor helpers mem_fun1 and mem_fun1_ref are provided for
backwards compatibility.
</ul></p>
<p>20.4.1 can use several different allocators; they are described on the
main extensions page.
</p>
<p>20.4.3 is extended with a special version of
<code>get_temporary_buffer</code> taking a second argument. The argument
is a pointer, which is ignored, but can be used to specify the template
......
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