Commit 5d5e5e4e by Phil Edwards

configopts.html: HTML to XHTML change.

2001-09-17  Phil Edwards  <pme@gcc.gnu.org>

	* docs/html/configopts.html:  HTML to XHTML change.  Lowercase tags.
	* docs/html/documentation.html:  Likewise.
	* docs/html/explanations.html:  Likewise.
	* docs/html/install.html:  Likewise.
	* docs/html/17_intro/howto.html:  Likewise.
	* docs/html/18_support/howto.html:  Likewise.
	* docs/html/19_diagnostics/howto.html:  Likewise.
	* docs/html/20_util/howto.html:  Likewise.
	* docs/html/21_strings/howto.html:  Likewise.
	* docs/html/22_locale/codecvt.html:  Likewise.
	* docs/html/22_locale/ctype.html:  Likewise.
	* docs/html/22_locale/howto.html:  Likewise.
	* docs/html/22_locale/locale.html:  Likewise.
	* docs/html/22_locale/messages.html:  Likewise.
	* docs/html/23_containers/howto.html:  Likewise.
	* docs/html/24_iterators/howto.html:  Likewise.
	* docs/html/25_algorithms/howto.html:  Likewise.
	* docs/html/26_numerics/howto.html:  Likewise.
	* docs/html/27_io/howto.html:  Likewise.
	* docs/html/ext/howto.html:  Likewise.
	* docs/html/faq/index.html:  Likewise.
	* docs/html/faq/index.txt:  Regenerated.

From-SVN: r45668
parent 5c701bb1
2001-09-17 Phil Edwards <pme@gcc.gnu.org>
* docs/html/configopts.html: HTML to XHTML change. Lowercase tags.
* docs/html/documentation.html: Likewise.
* docs/html/explanations.html: Likewise.
* docs/html/install.html: Likewise.
* docs/html/17_intro/howto.html: Likewise.
* docs/html/18_support/howto.html: Likewise.
* docs/html/19_diagnostics/howto.html: Likewise.
* docs/html/20_util/howto.html: Likewise.
* docs/html/21_strings/howto.html: Likewise.
* docs/html/22_locale/codecvt.html: Likewise.
* docs/html/22_locale/ctype.html: Likewise.
* docs/html/22_locale/howto.html: Likewise.
* docs/html/22_locale/locale.html: Likewise.
* docs/html/22_locale/messages.html: Likewise.
* docs/html/23_containers/howto.html: Likewise.
* docs/html/24_iterators/howto.html: Likewise.
* docs/html/25_algorithms/howto.html: Likewise.
* docs/html/26_numerics/howto.html: Likewise.
* docs/html/27_io/howto.html: Likewise.
* docs/html/ext/howto.html: Likewise.
* docs/html/faq/index.html: Likewise.
* docs/html/faq/index.txt: Regenerated.
2001-09-14 Phil Edwards <pme@sources.redhat.com>
* docs/html/17_intro/headers_cc.txt: "Sync"/copy real file over.
......
<!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 the libstdc++ chapter 19.">
<META NAME="GENERATOR" CONTENT="vi and eight fingers">
<TITLE>libstdc++-v3 HOWTO: Chapter 19</TITLE>
<LINK REL=StyleSheet HREF="../lib3styles.css">
<!-- $Id: howto.html,v 1.4 2001/05/30 21:54:59 pme Exp $ -->
</HEAD>
<BODY>
<html>
<head>
<meta HcodeP-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 the libstdc++ chapter 19.">
<meta NAME="GENERATOR" CONTENT="vi and eight fingers">
<title>libstdc++-v3 HOWTO: Chapter 19</title>
<link REL=StyleSheet HREF="../lib3styles.css">
<!-- $Id: howto.html,v 1.5 2001/09/15 00:41:11 pme Exp $ -->
</head>
<body>
<H1 CLASS="centered"><A NAME="top">Chapter 19: Diagnostics</A></H1>
<h1 CLASS="centered"><a name="top">Chapter 19: Diagnostics</a></h1>
<P>Chapter 19 deals with program diagnostics, such as exceptions
<p>Chapter 19 deals with program diagnostics, such as exceptions
and assertions. You know, all the things we wish weren't even
necessary at all.
</P>
</p>
<!-- ####################################################### -->
<HR>
<H1>Contents</H1>
<UL>
<LI><A HREF="#1">Adding data to exceptions</A>
<LI><A HREF="#2">Exception class hierarchy diagram</A>
<LI><A HREF="#3">Concept checkers -- <STRONG>new and improved!</STRONG></A>
</UL>
<hr>
<h1>Contents</h1>
<ul>
<li><a href="#1">Adding data to exceptions</a>
<li><a href="#2">Exception class hierarchy diagram</a>
<li><a href="#3">Concept checkers -- <strong>new and improved!</strong></a>
</ul>
<HR>
<hr>
<!-- ####################################################### -->
<H2><A NAME="1">Adding data to exceptions</A></H2>
<P>The standard exception classes carry with them a single string as
<h2><a name="1">Adding data to exceptions</a></h2>
<p>The standard exception classes carry with them a single string as
data (usually describing what went wrong or where the 'throw' took
place). It's good to remember that you can add your own data to
these exceptions when extending the heirarchy:
</P>
</p>
<PRE>
using std::runtime_error;
struct My_Exception : public runtime_error
......@@ -53,71 +53,71 @@
DBID id; // some user-defined type
};
</PRE>
<P>Return <A HREF="#top">to top of page</A> or
<A HREF="../faq/index.html">to the FAQ</A>.
</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="2">Exception class hierarchy diagram</A></H2>
<P>At one point we were going to make up a PDF of the exceptions
<hr>
<h2><a name="2">Exception class hierarchy diagram</a></h2>
<p>At one point we were going to make up a PDF of the exceptions
hierarchy, akin to the one done for the I/O class hierarchy.
Time was our enemy. Since then we've moved to Doxygen, which has
the useful property of not sucking. Specifically, when the source
code is changed, the diagrams are automatically brought up to date.
For the old way, we had to update the diagrams separately.
</P>
<P>There are several links to the Doxygen-generated pages from
<A HREF="../documentation.html">here</A>.
</P>
<P>Return <A HREF="#top">to top of page</A> or
<A HREF="../faq/index.html">to the FAQ</A>.
</P>
</p>
<p>There are several links to the Doxygen-generated pages from
<a href="../documentation.html">here</a>.
</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="3">Concept checkers -- <STRONG>new and improved!</STRONG></A></H2>
<P>Better taste! Less fat! Literally!</P>
<P>In 1999, SGI added <EM>concept checkers</EM> to their implementation
<hr>
<h2><a name="3">Concept checkers -- <strong>new and improved!</strong></a></h2>
<p>Better taste! Less fat! Literally!</p>
<p>In 1999, SGI added <em>concept checkers</em> to their implementation
of the STL: code which checked the template parameters of
instantiated pieces of the STL, in order to insure that the parameters
being used met the requirements of the standard. For example,
the Standard requires that types passed as template parameters to
<TT>vector</TT> be &quot;Assignable&quot; (which means what you think
<code>vector</code> be &quot;Assignable&quot; (which means what you think
it means). The checking was done during compilation, and none of
the code was executed at runtime.
</P>
<P>Unfortunately, the size of the compiler files grew significantly
</p>
<p>Unfortunately, the size of the compiler files grew significantly
as a result. The checking code itself was cumbersome. And bugs
were found in it on more than one occasion.
</P>
<P>The primary author of the checking code, Jeremy Siek, had already
</p>
<p>The primary author of the checking code, Jeremy Siek, had already
started work on a replcement implementation. The new code has been
formally reviewed and accepted into
<A HREF="http://www.boost.org/libs/concept_check/concept_check.htm">the
Boost libraries</A>, and we are pleased to incorporate it into the
<a href="http://www.boost.org/libs/concept_check/concept_check.htm">the
Boost libraries</a>, and we are pleased to incorporate it into the
GNU C++ library.
</P>
<P>The new version imposes a much smaller space overhead on the generated
</p>
<p>The new version imposes a much smaller space overhead on the generated
object file. The checks are also cleaner and easier to read and
understand.
</P>
<P>Right now they are off by default. More will be added once
</p>
<p>Right now they are off by default. More will be added once
GCC 3.0 is released and we have time to revisit this topic.
</P>
</p>
<P>Return <A HREF="#top">to top of page</A> or
<A HREF="../faq/index.html">to the FAQ</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>
<hr>
<P CLASS="fineprint"><em>
Comments and suggestions are welcome, and may be sent to
<A HREF="mailto:libstdc++@gcc.gnu.org">the mailing list</A>.
<BR> $Id: howto.html,v 1.4 2001/05/30 21:54:59 pme Exp $
</EM></P>
<a href="mailto:libstdc++@gcc.gnu.org">the mailing list</a>.
<br> $Id: howto.html,v 1.5 2001/09/15 00:41:11 pme Exp $
</em></p>
</BODY>
</HTML>
</body>
</html>
<HTML>
<HEAD>
<H1>
<html>
<head>
<h1>
Notes on the ctype implementation.
</H1>
</HEAD>
</h1>
</head>
<I>
prepared by Benjamin Kosnik (bkoz@redhat.com) on August 30, 2000
</I>
<P>
<H2>
<p>
<h2>
1. Abstract
</H2>
<P>
</h2>
<p>
Woe is me.
</P>
</p>
<P>
<H2>
<p>
<h2>
2. What the standard says
</H2>
</h2>
<P>
<H2>
<p>
<h2>
3. Problems with &quot;C&quot; ctype : global locales, termination.
</H2>
</h2>
<P>
<p>
For the required specialization codecvt&lt;wchar_t, char, mbstate_t&gt; ,
conversions are made between the internal character set (always UCS4
on GNU/Linux) and whatever the currently selected locale for the
LC_CTYPE category implements.
<P>
<H2>
<p>
<h2>
4. Design
</H2>
</h2>
The two required specializations are implemented as follows:
<P>
<TT>
<p>
<code>
ctype&lt;char&gt;
</TT>
<P>
</code>
<p>
This is simple specialization. Implementing this was a piece of cake.
<P>
<TT>
<p>
<code>
ctype&lt;wchar_t&gt;
</TT>
<P>
</code>
<p>
This specialization, by specifying all the template parameters, pretty
much ties the hands of implementors. As such, the implementation is
straightforward, involving mcsrtombs for the conversions between char
to wchar_t and wcsrtombs for conversions between wchar_t and char.
<P>
<p>
Neither of these two required specializations deals with Unicode
characters. As such, libstdc++-v3 implements
<P>
<H2>
<p>
<h2>
5. Examples
</H2>
</h2>
<pre>
typedef ctype<char> cctype;
</pre>
More information can be found in the following testcases:
<UL>
<LI> testsuite/22_locale/ctype_char_members.cc
<LI> testsuite/22_locale/ctype_wchar_t_members.cc
</UL>
<ul>
<li> testsuite/22_locale/ctype_char_members.cc
<li> testsuite/22_locale/ctype_wchar_t_members.cc
</ul>
<P>
<H2>
<p>
<h2>
6. Unresolved Issues
</H2>
</h2>
<UL>
<LI> how to deal with the global locale issue?
<ul>
<li> how to deal with the global locale issue?
<LI> how to deal with different types than char, wchar_t?
<li> how to deal with different types than char, wchar_t?
<LI> codecvt/ctype overlap: narrow/widen
<li> codecvt/ctype overlap: narrow/widen
<LI> mask typedef in codecvt_base, argument types in codecvt.
<li> mask typedef in codecvt_base, argument types in codecvt.
what is know about this type?
<LI> why mask* argument in codecvt?
<li> why mask* argument in codecvt?
<LI> can this be made (more) generic? is there a simple way to
<li> can this be made (more) generic? is there a simple way to
straighten out the configure-time mess that is a by-product of
this class?
<LI> get the ctype<wchar_t>::mask stuff under control. Need to
<li> get the ctype<wchar_t>::mask stuff under control. Need to
make some kind of static table, and not do lookup evertime
somebody hits the do_is... functions. Too bad we can't just
redefine mask for ctype<wchar_t>
<LI> rename abstract base class. See if just smash-overriding
<li> rename abstract base class. See if just smash-overriding
is a better approach. Clarify, add sanity to naming.
</UL>
</ul>
<P>
<H2>
<p>
<h2>
7. Acknowledgments
</H2>
</h2>
Ulrich Drepper for patient answering of late-night questions, skeletal
examples, and C language expertise.
<P>
<H2>
<p>
<h2>
8. Bibliography / Referenced Documents
</H2>
</h2>
Drepper, Ulrich, GNU libc (glibc) 2.2 manual. In particular, Chapters &quot;6. Character Set Handling&quot; and &quot;7 Locales and Internationalization&quot;
<P>
<p>
Drepper, Ulrich, Numerous, late-night email correspondence
<P>
<p>
ISO/IEC 14882:1998 Programming languages - C++
<P>
<p>
ISO/IEC 9899:1999 Programming languages - C
<P>
<p>
Langer, Angelika and Klaus Kreft, Standard C++ IOStreams and Locales, Advanced Programmer's Guide and Reference, Addison Wesley Longman, Inc. 2000
<P>
<p>
Stroustrup, Bjarne, Appendix D, The C++ Programming Language, Special Edition, Addison Wesley, Inc. 2000
<P>
<p>
System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x)
The Open Group/The Institute of Electrical and Electronics Engineers, Inc.
http://www.opennc.org/austin/docreg.html
......
<HTML>
<HEAD>
<H1>
<html>
<head>
<h1>
Notes on the locale implementation.
</H1>
</HEAD>
</h1>
</head>
<I>
prepared by Benjamin Kosnik (bkoz@redhat.com) on August 8, 2001
</I>
<P>
<H2>
<p>
<h2>
1. Abstract Describes the basic locale object, including nested
classes id, facet, and the reference-counted implementation object,
class _Impl.
</H2>
<P>
</P>
</h2>
<p>
</p>
<P>
<H2>
<p>
<h2>
2. What the standard says
See Chapter 22 of the standard.
</H2>
</h2>
<P>
<H2>
<p>
<h2>
3. Problems with &quot;C&quot; locales : global locales, termination.
</H2>
</h2>
<P>
<p>
The major problem is fitting an object-orientated and non-global locale
design ontop of POSIX and other relevant stanards, which include the
Single Unix (nee X/Open.)
Because POSIX falls down so completely, portibility is an issue.
<P>
<p>
<H2>
<h2>
4. Design
</H2>
</h2>
Class locale in non-templatized and has three distinct types nested
inside of it:
......@@ -69,34 +69,34 @@ Provides an index for looking up specific facets.
class _Impl
<P>
<H2>
<p>
<h2>
5. Examples
</H2>
</h2>
<pre>
typedef __locale_t locale;
</pre>
More information can be found in the following testcases:
<UL>
<LI> testsuite/22_locale/ctype_char_members.cc
<LI> testsuite/22_locale/ctype_wchar_t_members.cc
</UL>
<ul>
<li> testsuite/22_locale/ctype_char_members.cc
<li> testsuite/22_locale/ctype_wchar_t_members.cc
</ul>
<P>
<H2>
<p>
<h2>
6. Unresolved Issues
</H2>
</h2>
<UL>
<LI> locale -a displays available locales on linux
<ul>
<li> locale -a displays available locales on linux
<LI> locale initialization: at what point does _S_classic,
<li> locale initialization: at what point does _S_classic,
_S_global get initialized? Can named locales assume this
initialization has already taken place?
<LI> document how named locales error check when filling data
<li> document how named locales error check when filling data
members. Ie, a fr_FR locale that doesn't have
numpunct::truename(): does it use "true"? Or is it a blank
string? What's the convention?
......@@ -105,37 +105,37 @@ More information can be found in the following testcases:
use "de" information? What is the rule for locales composed of
just an ISO language code (say, "de") and locales with both an
ISO language code and ISO country code (say, "de_DE").
</UL>
</ul>
<P>
<H2>
<p>
<h2>
7. Acknowledgments
</H2>
</h2>
<P>
<H2>
<p>
<h2>
8. Bibliography / Referenced Documents
</H2>
</h2>
Drepper, Ulrich, GNU libc (glibc) 2.2 manual. In particular, Chapters &quot;6. Character Set Handling&quot; and &quot;7 Locales and Internationalization&quot;
<P>
<p>
Drepper, Ulrich, Numerous, late-night email correspondence
<P>
<p>
ISO/IEC 14882:1998 Programming languages - C++
<P>
<p>
ISO/IEC 9899:1999 Programming languages - C
<P>
<p>
Langer, Angelika and Klaus Kreft, Standard C++ IOStreams and Locales, Advanced Programmer's Guide and Reference, Addison Wesley Longman, Inc. 2000
<P>
<p>
Stroustrup, Bjarne, Appendix D, The C++ Programming Language, Special Edition, Addison Wesley, Inc. 2000
<P>
<p>
System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x)
The Open Group/The Institute of Electrical and Electronics Engineers, Inc.
http://www.opennc.org/austin/docreg.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@sources.redhat.com (Phil Edwards)">
<META NAME="KEYWORDS" CONTENT="HOWTO, libstdc++, GCC, g++, libg++, STL">
<META NAME="DESCRIPTION" CONTENT="HOWTO for the libstdc++ chapter 25.">
<META NAME="GENERATOR" CONTENT="vi and eight fingers">
<TITLE>libstdc++-v3 HOWTO: Chapter 25</TITLE>
<LINK REL=StyleSheet HREF="../lib3styles.css">
<!-- $Id: howto.html,v 1.3 2001/05/30 21:55:02 pme Exp $ -->
</HEAD>
<BODY>
<html>
<head>
<meta HcodeP-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 the libstdc++ chapter 25.">
<meta NAME="GENERATOR" CONTENT="vi and eight fingers">
<title>libstdc++-v3 HOWTO: Chapter 25</title>
<link REL=StyleSheet HREF="../lib3styles.css">
<!-- $Id: howto.html,v 1.4 2001/09/15 00:41:11 pme Exp $ -->
</head>
<body>
<H1 CLASS="centered"><A NAME="top">Chapter 25: Algorithms</A></H1>
<h1 CLASS="centered"><a name="top">Chapter 25: Algorithms</a></h1>
<P>Chapter 25 deals with the generalized subroutines for automatically
<p>Chapter 25 deals with the generalized subroutines for automatically
transforming lemmings into gold.
</P>
</p>
<!-- ####################################################### -->
<HR>
<H1>Contents</H1>
<UL>
<LI><A HREF="#1">Prerequisites</A>
<LI><A HREF="#2">Topic</A>
</UL>
<hr>
<h1>Contents</h1>
<ul>
<li><a href="#1">Prerequisites</a>
<li><a href="#2">Topic</a>
</ul>
<HR>
<hr>
<!-- ####################################################### -->
<H2><A NAME="1">Prerequisites</A></H2>
<P>The neatest accomplishment of the algorithms chapter is that all the
<h2><a name="1">Prerequisites</a></h2>
<p>The neatest accomplishment of the algorithms chapter is that all the
work is done via iterators, not containers directly. This means two
important things:
<OL>
<LI>Anything that behaves like an iterator can be used in one of
<ol>
<li>Anything that behaves like an iterator can be used in one of
these algorithms. Raw pointers make great candidates, thus
built-in arrays are fine containers, as well as your own iterators.
<LI>The algorithms do not (and cannot) affect the container as a
<li>The algorithms do not (and cannot) affect the container as a
whole; only the things between the two iterator endpoints. If
you pass a range of iterators only enclosing the middle third of
a container, then anything outside that range is inviolate.
</OL>
</P>
<P>Even strings can be fed through the algorithms here, although the
</ol>
</p>
<p>Even strings can be fed through the algorithms here, although the
string class has specialized versions of many of these functions (for
example, <TT>string::find()</TT>). Most of the examples on this
example, <code>string::find()</code>). Most of the examples on this
page will use simple arrays of integers as a playground for
algorithms, just to keep things simple.
<A NAME="Nsize">The use of <B>N</B></A> as a size in the examples is
<a name="Nsize">The use of <B>N</B></a> as a size in the examples is
to keep things easy to read but probably won't be legal code. You can
use wrappers such as those described in the
<A HREF="../23_containers/howto.html">containers chapter</A> to keep
<a href="../23_containers/howto.html">containers chapter</a> to keep
real code readable.
</P>
<P>The single thing that trips people up the most is the definition of
<EM>range</EM> used with iterators; the famous
</p>
<p>The single thing that trips people up the most is the definition of
<em>range</em> used with iterators; the famous
&quot;past-the-end&quot; rule that everybody loves to hate. The
<A HREF="../24_iterators/howto.html#2">iterators chapter</A> of this
<a href="../24_iterators/howto.html#2">iterators chapter</a> of this
document has a complete explanation of this simple rule that seems to
cause so much confusion. Once you get <EM>range</EM> into your head
cause so much confusion. Once you get <em>range</em> into your head
(it's not that hard, honest!), then the algorithms are a cakewalk.
</P>
<P>
</P>
<P>Return <A HREF="#top">to top of page</A> or
<A HREF="../faq/index.html">to the FAQ</A>.
</P>
</p>
<p>
</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="2">Topic</A></H2>
<P>Blah.
</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="2">Topic</a></h2>
<p>Blah.
</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>
<hr>
<P CLASS="fineprint"><em>
Comments and suggestions are welcome, and may be sent to
<A HREF="mailto:libstdc++@gcc.gnu.org">the mailing list</A>.
<BR> $Id: howto.html,v 1.3 2001/05/30 21:55:02 pme Exp $
</EM></P>
<a href="mailto:libstdc++@gcc.gnu.org">the mailing list</a>.
<br> $Id: howto.html,v 1.4 2001/09/15 00:41:11 pme Exp $
</em></p>
</BODY>
</HTML>
</body>
</html>
<HTML>
<HEAD>
<META NAME="KEYWORDS" CONTENT="libstdc++, homepage, home, g++, libg++, STL">
<TITLE>Standard C++ Library v3</TITLE>
<LINK REL=StyleSheet HREF="lib3styles.css">
<!-- $Id: documentation.html,v 1.4 2001/05/30 21:54:56 pme Exp $ -->
</HEAD>
<BODY>
<html>
<head>
<meta NAME="KEYWORDS" CONTENT="libstdc++, homepage, home, g++, libg++, STL">
<title>Standard C++ Library v3</title>
<link REL=StyleSheet HREF="lib3styles.css">
<!-- $Id: documentation.html,v 1.5 2001/06/15 22:57:30 pme Exp $ -->
</head>
<body>
<P><B>All of these documents</B> (in fact, this entire homepage set) are
bundled with the library source, under the <TT>docs</TT> subdirectory,
<p><B>All of these documents</B> (in fact, this entire homepage set) are
bundled with the library source, under the <code>docs</code> subdirectory,
for releases and snapshots. The sole exception is the
automatically-generated source documentation, available separately.
</P>
</p>
<HR>
<H2><A NAME="4">Source Documentation</A></H2>
<P>In addition to the distribution documentation (these pages), we also
<hr>
<h2><a name="4">Source Documentation</a></h2>
<p>In addition to the distribution documentation (these pages), we also
have a set of HTML documents generated from the sources themselves,
using the Doxygen tool. These are useful for examining the signatures
of public member functions for the library classes, etc.
</P>
<P>
</p>
<p>
The latest collection is for the GCC 3.0 release,
<TT>libstdc++-doxygen-3.0.tar.gz</TT> (3.8MB),
<A HREF="libstdc++-doxygen-3.0/index.html">viewable online</A>.
<code>libstdc++-doxygen-3.0.tar.gz</code> (3.8MB),
<a href="libstdc++-doxygen-3.0/index.html">viewable online</a>.
The collection is also available in the libstdc++ snapshots directory at
<TT>&lt;URL:ftp://gcc.gnu.org/pub/gcc/libstdc++/&gt;</TT>. You will
<code>&lt;URL:ftp://gcc.gnu.org/pub/gcc/libstdc++/&gt;</code>. You will
almost certainly need to use one of the
<A HREF="http://gcc.gnu.org/mirrors.html">mirror sites</A> to download
<a href="http://gcc.gnu.org/mirrors.html">mirror sites</a> to download
the tarball. After unpacking, simply load
libstdc++-doxygen-3.0/index.html <!-- also update this date -->
in a browser. Feedback (and additional documentation!) is welcome.
</P>
</p>
<!-- another paragraph here for post-release collections -->
<HR>
<H2><A NAME="2">Configuring, Building, Installing</A></H2>
<UL>
<LI><A HREF="configopts.html">Configure options</A>
<LI><A HREF="install.html">Getting started: configure, build, install</A><BR>
</UL>
<hr>
<h2><a name="2">Configuring, Building, Installing</a></h2>
<ul>
<li><a href="configopts.html">Configure options</a>
<li><a href="install.html">Getting started: configure, build, install</a><br>
</ul>
<HR>
<H2><A NAME="1">Introductory notes for libstdc++</A></H2>
<P>This is a short list of text files pertaining to this
<hr>
<h2><a name="1">Introductory notes for libstdc++</a></h2>
<p>This is a short list of text files pertaining to this
implementation of ISO 14882. A brief description follows the name
of the file.
</P>
<P>
<UL>
<LI><A HREF="17_intro/BADNAMES">BADNAMES</A>
</p>
<p>
<ul>
<li><a href="17_intro/BADNAMES">BADNAMES</a>
- names to avoid because of potential collisions
<LI><A HREF="17_intro/BUGS">BUGS</A>
<LI><A HREF="17_intro/C++STYLE">C++STYLE</A>
<li><a href="17_intro/BUGS">BUGS</a>
<li><a href="17_intro/C++STYLE">C++STYLE</a>
- coding style by example
<LI><A HREF="17_intro/CHECKLIST">CHECKLIST</A>
<li><a href="17_intro/CHECKLIST">CHECKLIST</a>
- a list of required features and their status.
<LI><A HREF="17_intro/COPYING">COPYING</A>
<li><a href="17_intro/COPYING">COPYING</a>
- GPL v2 license terms
<LI><A HREF="17_intro/DESIGN">DESIGN</A>
<li><a href="17_intro/DESIGN">DESIGN</a>
- overview of the implementation plan
<LI><A HREF="17_intro/HEADER_POLICY">HEADER_POLICY</A>
<li><a href="17_intro/headER_POLICY">headER_POLICY</a>
- header naming and sub-include structure
<LI><A HREF="17_intro/PROBLEMS">PROBLEMS</A>
<li><a href="17_intro/PROBLEMS">PROBLEMS</a>
<!-- Linking to "../README" doesn't work; we are at the top level
of the web pages. Punt. -->
<LI>README - directory structure
<LI><A HREF="17_intro/RELEASE-NOTES">RELEASE-NOTES</A>
<li>README - directory structure
<li><a href="17_intro/RELEASE-NOTES">RELEASE-NOTES</a>
- instructions for building, using
<LI><A HREF="17_intro/TODO">TODO</A>
<li><a href="17_intro/TODO">TODO</a>
- tasks and known bugs
<LI><A HREF="17_intro/organization">organization</A>
<LI><A HREF="17_intro/contribute.html">Contributor checklist</A>
<LI><A HREF="17_intro/libstdc++-assign.txt">Copyright assignment form for libstdc++-v3</A>
</UL>
</P>
<li><a href="17_intro/organization">organization</a>
<li><a href="17_intro/contribute.html">Contributor checklist</a>
<li><a href="17_intro/libstdc++-assign.txt">Copyright assignment form for libstdc++-v3</a>
</ul>
</p>
<HR>
<H2><A NAME="3">Chapter-Specific Information, Extensions, Notes and Advice</A></H2>
<OL>
<LI><A HREF="17_intro/howto.html">Chapter 17 (Intro)</A>
<LI><A HREF="18_support/howto.html">Chapter 18 (Library Support)</A>
<LI><A HREF="19_diagnostics/howto.html">Chapter 19 (Diagnostics)</A>
<LI><A HREF="20_util/howto.html">Chapter 20 (Utilities)</A>
<LI><A HREF="21_strings/howto.html">Chapter 21 (Strings)</A>
<LI><A HREF="22_locale/howto.html">Chapter 22 (Localization)</A>
<LI><A HREF="23_containers/howto.html">Chapter 23 (Containers)</A>
<LI><A HREF="24_iterators/howto.html">Chapter 24 (Iterators)</A>
<LI><A HREF="25_algorithms/howto.html">Chapter 25 (Algorithms)</A>
<LI><A HREF="26_numerics/howto.html">Chapter 26 (Numerics)</A>
<LI><A HREF="27_io/howto.html">Chapter 27 (I/O)</A>
<LI><A HREF="ext/howto.html">Extensions to the Standard Library</A>
</OL>
<hr>
<h2><a name="3">Chapter-Specific Information, Extensions, Notes and Advice</a></h2>
<ol>
<li><a href="17_intro/howto.html">Chapter 17 (Intro)</a>
<li><a href="18_support/howto.html">Chapter 18 (Library Support)</a>
<li><a href="19_diagnostics/howto.html">Chapter 19 (Diagnostics)</a>
<li><a href="20_util/howto.html">Chapter 20 (Utilities)</a>
<li><a href="21_strings/howto.html">Chapter 21 (Strings)</a>
<li><a href="22_locale/howto.html">Chapter 22 (Localization)</a>
<li><a href="23_containers/howto.html">Chapter 23 (Containers)</a>
<li><a href="24_iterators/howto.html">Chapter 24 (Iterators)</a>
<li><a href="25_algorithms/howto.html">Chapter 25 (Algorithms)</a>
<li><a href="26_numerics/howto.html">Chapter 26 (Numerics)</a>
<li><a href="27_io/howto.html">Chapter 27 (I/O)</a>
<li><a href="ext/howto.html">Extensions to the Standard Library</a>
</ol>
</BODY>
</HTML>
</body>
</html>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<HTML>
<HEAD>
<META NAME="AUTHOR" CONTENT="pme@sources.redhat.com (Phil Edwards)">
<META NAME="KEYWORDS" CONTENT="libstdc++, libstdc++-v3, GCC, g++">
<META NAME="DESCRIPTION" CONTENT="Explanatory notes about libstdc++-v3.">
<META NAME="GENERATOR" CONTENT="vi and eight fingers">
<TITLE>Explanatory notes about libstdc++-v3 design</TITLE>
<LINK REL=StyleSheet HREF="lib3styles.css">
<!-- $Id: configopts.html,v 1.10 2001/04/20 08:59:25 bkoz Exp $ -->
</HEAD>
<BODY>
<html>
<head>
<meta NAME="AUTHOR" CONTENT="pme@gcc.gnu.org (Phil Edwards)">
<meta NAME="KEYWORDS" CONTENT="libstdc++, libstdc++-v3, GCC, g++">
<meta NAME="DESCRIPTION" CONTENT="Explanatory notes about libstdc++-v3.">
<meta NAME="GENERATOR" CONTENT="vi and eight fingers">
<title>Explanatory notes about libstdc++-v3 design</title>
<link REL=StyleSheet HREF="lib3styles.css">
<!-- $Id: explanations.html,v 1.1 2001/07/09 19:37:01 pme Exp $ -->
</head>
<body>
<H1 CLASS="centered"><A NAME="top">Explanatory notes about libstdc++-v3
design</A></H1>
<h1 CLASS="centered"><a name="top">Explanatory notes about libstdc++-v3
design</a></h1>
<P>The latest version of this document is always available at
<A HREF="http://gcc.gnu.org/onlinedocs/libstdc++/explanations.html">
http://gcc.gnu.org/onlinedocs/libstdc++/explanations.html</A>.
</P>
<p>The latest version of this document is always available at
<a href="http://gcc.gnu.org/onlinedocs/libstdc++/explanations.html">
http://gcc.gnu.org/onlinedocs/libstdc++/explanations.html</a>.
</p>
<P>To the <A HREF="http://gcc.gnu.org/libstdc++/">libstdc++-v3 homepage</A>.
<p>To the <a href="http://gcc.gnu.org/libstdc++/">libstdc++-v3 homepage</a>.
<!-- ####################################################### -->
<HR>
<A NAME="cstdio"><H3>&quot;I/O packages&quot;, <TT>--enable-cstdio</TT></H3></A>
<P>In addition to all the nifty things which C++ can do for I/O, its library
<hr>
<a name="cstdio"><h3>&quot;I/O packages&quot;, <code>--enable-cstdio</code></h3></a>
<p>In addition to all the nifty things which C++ can do for I/O, its library
also includes all of the I/O capabilites of C. Making them work together
can be a challenge, not only
<A HREF="27_io/howto.html#8">for the programmer</A> but for the
<a href="27_io/howto.html#8">for the programmer</a> but for the
implementors as well.
</P>
<P>There are two ways to do a C++ library: the cool way, and the easy way.
</p>
<p>There are two ways to do a C++ library: the cool way, and the easy way.
More specifically, the cool-but-easy-to-get-wrong way, and the
easy-to-guarantee-correct-behavior way. For 3.0, the easy way is used.
</P>
<P>Choosing 'stdio' is the easy way. It builds a C++ library which forwards
</p>
<p>Choosing 'stdio' is the easy way. It builds a C++ library which forwards
all operations to the C library. Many of the C++ I/O functions are
specified in the standard 'as if' they called a certain C function; the
easiest way to get it correct is to actually call that function. The
disadvantage is that the C++ code will run slower (fortunately, the layer
is thin).
</P>
<P>Choosing 'libio' is the cool way; it allows C++ and C to share some
</p>
<p>Choosing 'libio' is the cool way; it allows C++ and C to share some
buffers. It's disabled because of tricky synchronization issues. Other
cool ways (various methods of sharing resources between C and C++
facilities, instead of layering) are possible. This approach can speed
up I/O significantly.
</P>
<P>Other packages are possible. For a new package, a header must be
</p>
<p>Other packages are possible. For a new package, a header must be
written to provide types like streamsize (usually just a typedef), as
well as some internal types like<TT> __c_file_type </TT> and
<TT> __c_lock </TT> (for the stdio case, these are FILE (as in
well as some internal types like<code> __c_file_type </code> and
<code> __c_lock </code> (for the stdio case, these are FILE (as in
&quot;FILE*&quot;) and a simple POSIX mutex, respectively). An
interface class called <TT> __basic_file </TT> must also be filled in;
interface class called <code> __basic_file </code> must also be filled in;
as an example, for the stdio case, these member functions are all
inline calles to fread, fwrite, etc.
</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>
</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>
<P CLASS="fineprint"><EM>
$Id$
</EM></P>
<hr>
<P CLASS="fineprint"><em>
$Id: explanations.html,v 1.1 2001/07/09 19:37:01 pme Exp $
</em></p>
</BODY>
</HTML>
</body>
</html>
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