mirror of git://gcc.gnu.org/git/gcc.git
166 lines
7.7 KiB
HTML
166 lines
7.7 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)">
|
|
<meta name="KEYWORDS" content="HOWTO, libstdc++, gcc, g++, libg++, STL">
|
|
<meta name="DESCRIPTION" content="HOWTO for libstdc++ chapter 17.">
|
|
<meta name="GENERATOR" content="vi and eight fingers">
|
|
<title>libstdc++-v3 HOWTO: Chapter 17</title>
|
|
<link rel="StyleSheet" href="../lib3styles.css">
|
|
</head>
|
|
<body>
|
|
|
|
<h1 class="centered"><a name="top">Chapter 17: Library Introduction</a></h1>
|
|
|
|
<p>Chapter 17 is actually a list of definitions and descriptions used
|
|
in the following chapters of the Standard when describing the actual
|
|
library. Here, we use "Introduction" as an introduction
|
|
to the <em>GNU implementation of</em> the ISO Standard C++ Library.
|
|
</p>
|
|
|
|
|
|
<!-- ####################################################### -->
|
|
<hr>
|
|
<h1>Contents</h1>
|
|
<ul>
|
|
<li><a href="#2">The Standard C++ header files</a>
|
|
<li><a href="#3">Thread-safety</a>
|
|
<li><a href="#4"><code><foo></code> vs <code><foo.h></code></a>
|
|
<li><a href="porting-howto.html">Porting HOWTO</a>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<!-- ####################################################### -->
|
|
|
|
<h2><a name="2">The Standard C++ header files</a></h2>
|
|
<p>The Standard C++ Library specifies 50 header files that must be
|
|
available to all hosted implementations. Actually, the word
|
|
"files" is a misnomer, since the contents of the headers
|
|
don't necessarily have to be in any kind of external file. The
|
|
only rule is that when you <code>#include</code> a certain header, the
|
|
contents of that header, as defined by the Standard, become
|
|
available to you, no matter how.
|
|
</p>
|
|
<p>The names of the headers can be easily seen in
|
|
<a href="headers_cc.txt"><code>testsuite/17_intro/headers.cc</code></a>,
|
|
which is a small testbed we use to make certain that the headers
|
|
all compile and run.
|
|
</p>
|
|
|
|
<hr>
|
|
<h2><a name="3">Thread-safety</a></h2>
|
|
<p>This is a thorny issue that gets brought up on the libstdc++-v3
|
|
and gcc mailing lists on a regular basis (probably by a cron job).
|
|
This entry will mention a very little bit about the general MT
|
|
issues with libstdc++. The latest status and quick notes will be
|
|
in FAQ 5.6. Some discussion about thread-safe containers will be
|
|
in section 6.8 (the HOWTOs on containers). This section only applies
|
|
when gcc and libstdc++-v3 were configured with --enable-threads.
|
|
</p>
|
|
<p>The libstdc++ code (all of it, not just the containers) has been
|
|
designed so that thread-safety will be easily possible. The first
|
|
(!) problem is finding a <em>fast</em> method of implementation
|
|
portable to all platforms. A minor problem that pops up every so
|
|
often is different interpretations of what "thread-safe"
|
|
means for a library (not a general program). We currently use the
|
|
<a href="http://www.sgi.com/tech/stl/thread_safety.html">same
|
|
definition that SGI</a> uses for their STL subset.
|
|
<em>Please see the many cautions given in
|
|
<a href="../23_containers/howto.html">HOWTOs on containers</a>.</em>
|
|
</p>
|
|
<p>Here is another attempt at explaining the dangers of using the
|
|
STL with threading support without understanding some important
|
|
details. 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 support multi-threading, then please consult all commentary
|
|
in include/bits/c++config and the HOWTOs on containers. Be
|
|
fully aware that you may change the external or internal ABI of
|
|
libstdc++-v3 when you provide -D__USE_MALLOC on the command line
|
|
or make a change to that configuration file.
|
|
</p>
|
|
<p>If you don't like caches of objects being retained inside the STL, then
|
|
you might be tempted to define __USE_MALLOC either on the command
|
|
line or by rebuilding c++config.h. Please note, once you define
|
|
__USE_MALLOC, only the malloc allocator is visible to application code
|
|
(i.e. the typically higher-speed allocator is not even available
|
|
in this configuration). There is a better way: It is possible
|
|
to force the malloc-based allocator on a per-case-basis for some
|
|
application code even when the above macro symbol is not defined.
|
|
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 <my_type, std::malloc_alloc> my_malloc_based_list;</pre>
|
|
</p>
|
|
<p>A recent journal article has described "atomic integer
|
|
operations," which would allow us to, well, perform updates
|
|
on integers atomically, and without requiring an explicit mutex
|
|
lock. This appears promising, but the major difficulty is that
|
|
these operations "may not be available on all systems, and
|
|
if they are, may have different interfaces." [quoting from
|
|
mailing list messages]
|
|
</p>
|
|
<p>Here is a small link farm to threads (no pun) in the mail archives
|
|
that discuss the threading problem. Each link is to the first
|
|
relevent message in the thread; from there you can use
|
|
"Thread Next" to move down the thread. This farm is in
|
|
latest-to-oldest order.
|
|
<ul>
|
|
<li>Our threading expert Loren gives a breakdown of
|
|
<a href="http://gcc.gnu.org/ml/libstdc++/2001-10/msg00024.html">the
|
|
six situations involving threads</a> for the 3.0 release series.
|
|
<li><a href="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00384.html">
|
|
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
|
|
people with access to the backup tapes have been too swamped with work
|
|
to restore them. Many of the points have been superceded anyhow.)
|
|
</p>
|
|
<p>This section will be updated as new and interesting issues come
|
|
to light.
|
|
</p>
|
|
<p>Return <a href="#top">to top of page</a> or
|
|
<a href="../faq/index.html">to the FAQ</a>.
|
|
</p>
|
|
|
|
<hr>
|
|
<h2><a name="4"><code><foo></code> vs <code><foo.h></code></a></h2>
|
|
<p>The new-style headers are fully supported in libstdc++-v3. The compiler
|
|
itself fully supports namespaces, including <code>std::</code>.
|
|
</p>
|
|
<p>For those of you new to ISO C++98, no, that isn't a typo, the headers
|
|
really have new names. Marshall Cline's C++ FAQ Lite has a good
|
|
explanation in
|
|
<a href="http://www.cerfnet.com/~mpcline/On-Line-C++-FAQ/coding-standards.html#[25.4]">item [25.4]</a>.
|
|
</p>
|
|
<p>Return <a href="#top">to top of page</a> or
|
|
<a href="../faq/index.html">to the FAQ</a>.
|
|
</p>
|
|
|
|
|
|
|
|
<!-- ####################################################### -->
|
|
|
|
<hr>
|
|
<p class="fineprint"><em>
|
|
See <a href="license.html">license.html</a> for copying conditions.
|
|
Comments and suggestions are welcome, and may be sent to
|
|
<a href="mailto:libstdc++@gcc.gnu.org">the libstdc++ mailing list</a>.
|
|
</em></p>
|
|
|
|
|
|
</body>
|
|
</html>
|
|
|
|
|