gcc/libstdc++-v3/docs/html/17_intro/howto.html

203 lines
9.6 KiB
HTML
Raw Normal View History

<!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@sources.redhat.com (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">
<!-- $Id: howto.html,v 1.4 2001/05/30 21:54:57 pme Exp $ -->
</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 &quot;Introduction&quot; 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"><TT>&lt;foo&gt;</TT> vs <TT>&lt;foo.h&gt;</TT></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
&quot;files&quot; 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 <TT>#include</TT> 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"><TT>testsuite/17_intro/headers.cc</TT></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).
</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 &quot;thread-safe&quot;
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 HOWTOs on containers.</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. [Placeholder in
case other patches don't make it before the 3.0 release: That
memory allocator can appear buggy in multithreaded C++ programs
(and has been reported to leak memory), if STL is misconfigured
for your platform. You may need to provide -D_PTHREADS on the
command line in this case to ensure the memory allocator for
containers is really protected by a mutex. Also, be aware that
you just changed the ABI of libstdc++-v3 when you did that thus
your entire application and all libraries must be compiled with
compatible flags. The STL implementation doesn't currently
protect you from changing the mutex locking implementation to
one that doesn't really play together with the implementation
you may have compiled other application code with.]
</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 author of this
comment believes that 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:
std::list <void*, std::malloc_alloc> my_malloc_based_list;
</P>
<P>A recent journal article has described &quot;atomic integer
operations,&quot; 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 &quot;may not be available on all systems, and
if they are, may have different interfaces.&quot; [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
&quot;Thread Next&quot; to move down the thread. This farm is in
latest-to-oldest order.
<UL>
<LI><A HREF="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00384.html">
inspired this most recent updating of issues with threading
and the SGI STL library. It also contains some example
POSIX-multithreaded STL code.</A>
<LI> <A HREF="http://gcc.gnu.org/ml/libstdc++/2001-05/msg00136.html">
an early analysis of why __USE_MALLOC should be disable for
the 3.0 release of libstdc++.</A>
</UL>
<BR>
Here are discussions that took place before the current snapshot;
they are still relevant and instructive.
<BR>
<UL>
<LI>One way of preventing memory leaks by the old default memory
allocator in multithreaded code is
<A HREF="http://gcc.gnu.org/ml/gcc/1999-11n/msg00431.html">discussed here</A>.
<LI><A HREF="http://gcc.gnu.org/ml/libstdc++/1999-q3/msg00167.html">This thread
concerns strings</A>.
<LI><A HREF="http://gcc.gnu.org/ml/libstdc++/1999-q2/msg00339.html">So does this
one</A>. This initial message also refers to another
thread in the GCC mailing list...
<LI><A HREF="http://gcc.gnu.org/ml/gcc/1999-06n/msg00680.html">which is here</A>,
and goes on for some time. Ironically, the initial message
in this thread also mentions another threading thread...
<LI><A HREF="http://gcc.gnu.org/ml/gcc-bugs/1999-04n/msg00777.html">beginning here</A>,
and talking about pthreads. (Note that a much more recent
message from the first thread in this list notes that
<A HREF="http://gcc.gnu.org/ml/libstdc++/1999-q3/msg00176.html">pthreads
should not be used as a starting point</A> for making
libstdc++ threadsafe.)
<LI><A HREF="http://gcc.gnu.org/ml/libstdc++/1999-q2/msg00168.html">This
message</A>,
<A HREF="http://gcc.gnu.org/ml/libstdc++/1999-q2/msg00159.html">this one</A>,
and <A HREF="http://gcc.gnu.org/ml/libstdc++/1999-q2/msg00156.html">this one</A>
are the tops of related threads (all within the same time
period) discussing threading and the IO library. Much of it
is dealing with the C library, but C++ is included as well.
</UL>
</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"><TT>&lt;foo&gt;</TT> vs <TT>&lt;foo.h&gt;</TT></A></H2>
<P>The new-style headers are fully supported in libstdc++-v3. The compiler
itself fully supports namespaces, including <TT>std::</TT>.
</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>
Comments and suggestions are welcome, and may be sent to
New concept checking implementation. 2001-04-02 Phil Edwards <pme@sources.redhat.com> New concept checking implementation. * docs/html/19_diagnostics/howto.html: Document. * docs/html/17_intro/concept_check.diff: New file, for reference. * include/bits/boost_concept_check.h: New file from Boost. * include/bits/c++config: Update comments. * include/bits/concept_check.h: New file. * include/bits/concept_checks.h: Removed. * include/bits/container_concepts.h: Removed. * include/bits/sequence_concepts.h: Removed. * include/bits/stl_iterator_base.h: Removed; split into... * include/bits/stl_iterator_base_funcs.h: ...this new file... * include/bits/stl_iterator_base_types.h: ...and this new file. * include/bits/sbuf_iter.h: Update to use new implementation. * include/bits/std_iterator.h: Likewise. * include/bits/std_memory.h: Likewise. * include/bits/stl_algo.h: Likewise. * include/bits/stl_algobase.h: Likewise. * include/bits/stl_construct.h: Likewise. * include/bits/stl_deque.h: Likewise. * include/bits/stl_heap.h: Likewise. * include/bits/stl_list.h: Likewise. * include/bits/stl_map.h: Likewise. * include/bits/stl_multimap.h: Likewise. * include/bits/stl_multiset.h: Likewise. * include/bits/stl_numeric.h: Likewise. * include/bits/stl_queue.h: Likewise. * include/bits/stl_set.h: Likewise. * include/bits/stl_stack.h: Likewise. * include/bits/stl_uninitialized.h: Likewise. * include/bits/stl_vector.h: Likewise. * include/ext/hash_map: Likewise. * include/ext/hash_set: Likewise. * include/ext/slist: Likewise. * include/ext/stl_hashtable.h: Likewise. * src/Makefile.am (base_headers): Update list of headers. * Makefile.in: Regenerated. * src/Makefile.in: Regenerated. * libio/Makefile.in: Regenerated. * libmath/Makefile.in: Regenerated. * libsupc++/Makefile.in: Regenerated. * testsuite/Makefile.in: Regenerated. * docs/html/install.html: Update contact information. * docs/html/17_intro/howto.html: Ditto. * docs/html/18_support/howto.html: Ditto. * docs/html/20_util/howto.html: Ditto. * docs/html/21_strings/howto.html: Ditto. * docs/html/22_locale/howto.html: Ditto. * docs/html/23_containers/howto.html: Ditto. * docs/html/24_iterators/howto.html: Ditto. * docs/html/25_algorithms/howto.html: Ditto. * docs/html/26_numerics/howto.html: Ditto. * docs/html/27_io/howto.html: Ditto. * docs/html/faq/index.html: Ditto, plus info on new checking code. * docs/html/ext/howto.html: Ditto, plus info on new checking code. * docs/html/faq/index.txt: Regenerated. From-SVN: r41031
2001-04-03 08:26:58 +08:00
<A HREF="mailto:libstdc++@gcc.gnu.org">the mailing list</A>.
<BR> $Id: howto.html,v 1.4 2001/05/30 21:54:57 pme Exp $
</EM></P>
</BODY>
</HTML>