Skip to content

R
riscv-gcc-1
Commit 462b7396 by Phil Edwards
Options

user.cfg.in: Minor addition. 

2001-05-30  Phil Edwards  <pme@sources.redhat.com>

	* docs/doxygen/user.cfg.in:  Minor addition.
	* docs/html/documentation.html:  Reorganize.  Put most-looked-at
	stuff first.
	* docs/html/install.html:  Update for 3.0.  HTML fixups.
	* 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/23_containers/howto.html:  Likewise.
	* docs/html/24_iterators/howto.html:  Likewise.  More notes.
	* docs/html/25_algorithms/howto.html:  Likewise.
	* docs/html/26_numerics/howto.html:  Likewise.  More notes.
	* docs/html/27_io/howto.html:  Likewise.
	* docs/html/ext/howto.html:  Likewise.
	* docs/html/faq/index.html:  Likewise.
	* docs/html/faq/index.txt:  Regenerate.
	* docs/html/27_io/iostreams_hierarchy.pdf:  Remove in favor of
	Doxygen-created documentation.

From-SVN: r42723
parent 932c1783
Showing with 270 additions and 210 deletions
libstdc++-v3/ChangeLog
2001-05-30 Phil Edwards <pme@sources.redhat.com>
* docs/doxygen/user.cfg.in: Minor addition.
* docs/html/documentation.html: Reorganize. Put most-looked-at
stuff first.
* docs/html/install.html: Update for 3.0. HTML fixups.
* 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/23_containers/howto.html: Likewise.
* docs/html/24_iterators/howto.html: Likewise. More notes.
* docs/html/25_algorithms/howto.html: Likewise.
* docs/html/26_numerics/howto.html: Likewise. More notes.
* docs/html/27_io/howto.html: Likewise.
* docs/html/ext/howto.html: Likewise.
* docs/html/faq/index.html: Likewise.
* docs/html/faq/index.txt: Regenerate.
* docs/html/27_io/iostreams_hierarchy.pdf: Remove in favor of
Doxygen-created documentation.
2001-05-30 Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
* testsuite/lib/libstdc++-v3-dg.exp (libstdc++-v3-init): Use
......
libstdc++-v3/docs/doxygen/user.cfg.in
......@@ -20,7 +20,7 @@
# The PROJECT_NAME tag is a single word (or a sequence of words surrounded
# by quotes) that should identify the project.
PROJECT_NAME = libstdc++-v3
PROJECT_NAME = "libstdc++-v3 Source"
# The PROJECT_NUMBER tag can be used to enter a project or revision number.
# This could be handy for archiving the generated documentation or
......
libstdc++-v3/docs/html/17_intro/howto.html
......@@ -8,7 +8,7 @@
<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.2 2001/04/03 00:26:54 pme Exp $ -->
<!-- $Id: howto.html,v 1.3 2001/05/30 08:30:02 ljrittle Exp $ -->
</HEAD>
<BODY>
......@@ -125,8 +125,7 @@
<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. However, at the moment, the compiler
treats std:: as the global namespace by default.
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
......@@ -145,7 +144,7 @@
<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.2 2001/04/03 00:26:54 pme Exp $
<BR> $Id: howto.html,v 1.3 2001/05/30 08:30:02 ljrittle Exp $
</EM></P>
......
libstdc++-v3/docs/html/18_support/howto.html
......@@ -8,7 +8,7 @@
<META NAME="GENERATOR" CONTENT="vi and eight fingers">
<TITLE>libstdc++-v3 HOWTO: Chapter 18</TITLE>
<LINK REL=StyleSheet HREF="../lib3styles.css">
<!-- $Id: howto.html,v 1.1 2000/12/10 04:04:54 pme Exp $ -->
<!-- $Id: howto.html,v 1.2 2001/04/03 00:26:55 pme Exp $ -->
</HEAD>
<BODY>
......@@ -186,6 +186,11 @@
out of them, Bad Things happen.
</OL>
</P>
<P>Note also that <TT>atexit()</TT> is only required to store 32
functions, and the compiler/library might already be using some of
those slots. If you think you may run out, we recommend using
the xatexit/xexit combination from libiberty, which has no such limit.
</P>
<P>Return <A HREF="#top">to top of page</A> or
<A HREF="../faq/index.html">to the FAQ</A>.
</P>
......@@ -260,7 +265,7 @@
<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.1 2000/12/10 04:04:54 pme Exp $
<BR> $Id: howto.html,v 1.2 2001/04/03 00:26:55 pme Exp $
</EM></P>
......
libstdc++-v3/docs/html/19_diagnostics/howto.html
......@@ -8,7 +8,7 @@
<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.2 2001/03/25 00:01:56 pme Exp $ -->
<!-- $Id: howto.html,v 1.3 2001/04/03 00:26:55 pme Exp $ -->
</HEAD>
<BODY>
......@@ -93,16 +93,8 @@
object file. The checks are also cleaner and easier to read and
understand.
</P>
<P>Concept checking can be disabled when you build your code, for example,
to save space during a production build. Just define (via -D or
#define) any of the macros
<TT>_GLIBCPP_NO_CONCEPT_CHECKS (yes, with the leading underscore),
<TT>_STL_NO_CONCEPT_CHECKS</TT> (also with the leading underscore),
or <TT>NDEBUG</TT>. The first macro is specifically for this
feature, the second is the disabling macro for the replaced SGI
version (some code may assume SGI's version is in use), and the third
is the usual macro to disable <TT>assert()</TT>, which is often turned
off for production builds.
<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>Return <A HREF="#top">to top of page</A> or
......@@ -116,7 +108,7 @@
<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.2 2001/03/25 00:01:56 pme Exp $
<BR> $Id: howto.html,v 1.3 2001/04/03 00:26:55 pme Exp $
</EM></P>
......
libstdc++-v3/docs/html/20_util/howto.html
......@@ -8,7 +8,7 @@
<META NAME="GENERATOR" CONTENT="vi and eight fingers">
<TITLE>libstdc++-v3 HOWTO: Chapter 20</TITLE>
<LINK REL=StyleSheet HREF="../lib3styles.css">
<!-- $Id: howto.html,v 1.2 2001/01/23 17:02:27 pme Exp $ -->
<!-- $Id: howto.html,v 1.3 2001/04/03 00:26:55 pme Exp $ -->
</HEAD>
<BODY>
......@@ -96,7 +96,7 @@
<PRE>
struct My_Type
{
My_Type (My_Type const&amp;);
My_Type (My_Type const&amp;);
};
</PRE>
Note the const keyword; the object being copied shouldn't change.
......@@ -120,23 +120,10 @@
void f()
{
std::vector&lt; std::auto_ptr&lt;int&gt; &gt; vec_ap_int;
std::vector&lt; std::auto_ptr&lt;int&gt; &gt; vec_ap_int;
}
</PRE>
Should you try this, you will see an error along the lines of the
following (look through the ugly line-wrapping):
<PRE>
/installdir/include/g++-v3/bits/concept_checks.h: In
static member function `static _Type
<B>_STL_ERROR::__const_parameter_required_for_copy_constructor</B>(_Type, const
_Type&amp;) [with _Type = std::auto_ptr&lt;int&gt;]':
/installdir/include/g++-v3/bits/concept_checks.h:383: passing
`const std::auto_ptr&lt;int&gt;' as `this' argument of
`std::auto_ptr&lt;_Tp&gt;::operator std::auto_ptr_ref&lt;_Tp1&gt;()
[with _Tp1 = int, _Tp = int]' discards qualifiers
</PRE>
See the highlighted error? It starts with a message in all caps
to get your attention.
Should you try this with the checks enabled, you will see an error.
</P>
<P>Return <A HREF="#top">to top of page</A> or
<A HREF="../faq/index.html">to the FAQ</A>.
......@@ -213,7 +200,7 @@
<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.2 2001/01/23 17:02:27 pme Exp $
<BR> $Id: howto.html,v 1.3 2001/04/03 00:26:55 pme Exp $
</EM></P>
......
libstdc++-v3/docs/html/23_containers/howto.html
......@@ -8,7 +8,7 @@
<META NAME="GENERATOR" CONTENT="vi and eight fingers">
<TITLE>libstdc++-v3 HOWTO: Chapter 23</TITLE>
<LINK REL=StyleSheet HREF="../lib3styles.css">
<!-- $Id: howto.html,v 1.2 2001/04/03 00:26:55 pme Exp $ -->
<!-- $Id: howto.html,v 1.3 2001/05/30 08:30:01 ljrittle Exp $ -->
</HEAD>
<BODY>
......@@ -45,10 +45,8 @@
algorithms are only given endpoints to work with. For the container
classes, these are iterators (usually <TT>begin()</TT> and
<TT>end()</TT>, but not always). For builtin arrays, these are
the address of the first element and the past-the-end element.
<!-- a good explanation of the past-the-end rules is in order,
probably a link somewhere
-->
the address of the first element and the
<A HREF="../24_iterators/howto.html#2">past-the-end</A> element.
</P>
<P>Some very simple wrapper functions can hide all of that from the
rest of the code. For example, a pair of functions called
......@@ -86,7 +84,7 @@
</P>
<P>Second, the line
<PRE>
inline unsigned int lengthof (T (&)[sz]) { return sz; } </PRE>
inline unsigned int lengthof (T (&amp;)[sz]) { return sz; } </PRE>
looks just weird! Hint: unused parameters can be left nameless.
</P>
<P>Return <A HREF="#top">to top of page</A> or
......@@ -134,7 +132,7 @@
some extra space, of course. (If you plan to write code like the
incorrect example above, where the bitset is a local variable, then you
may have to talk your compiler into allowing that much stack space;
there may be zero spae overhead, but it's all allocated inside the
there may be zero space overhead, but it's all allocated inside the
object.)
</P>
<P><B>A container&lt;bool&gt;.&nbsp;&nbsp;</B> The Committee made provision
......@@ -239,7 +237,7 @@
<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.2 2001/04/03 00:26:55 pme Exp $
<BR> $Id: howto.html,v 1.3 2001/05/30 08:30:01 ljrittle Exp $
</EM></P>
......
libstdc++-v3/docs/html/24_iterators/howto.html
......@@ -8,7 +8,7 @@
<META NAME="GENERATOR" CONTENT="vi and eight fingers">
<TITLE>libstdc++-v3 HOWTO: Chapter 24</TITLE>
<LINK REL=StyleSheet HREF="../lib3styles.css">
<!-- $Id: howto.html,v 1.1 2000/12/10 04:04:55 pme Exp $ -->
<!-- $Id: howto.html,v 1.2 2001/04/03 00:26:56 pme Exp $ -->
</HEAD>
<BODY>
......@@ -70,7 +70,98 @@
<HR>
<H2><A NAME="2">It ends <EM>where?</EM></A></H2>
<P>Blah.
<P>This starts off sounding complicated, but is actually very easy,
especially towards the end. Trust me.
</P>
<P>Beginners usually have a little trouble understand the whole
'past-the-end' thing, until they remember their early algebra classes
(see, they </EM>told</EM> you that stuff would come in handy!) and
the concept of half-open ranges.
</P>
<P>First, some history, and a reminder of some of the funkier rules in
C and C++ for builtin arrays. The following rules have always been
true for both languages:
<OL>
<LI>You can point anywhere in the array, <EM>or to the first element
past the end of the array</EM>. A pointer that points to one
past the end of the array is guaranteed to be as unique as a
pointer to somewhere inside the array, so that you can compare
such pointers safely.
<LI>You can only dereference a pointer that points into an array.
If your array pointer points outside the array -- even to just
one past the end -- and you dereference it, Bad Things happen.
<LI>Strictly speaking, simply pointing anywhere else invokes
undefined behavior. Most programs won't puke until such a
pointer is actually dereferenced, but the standards leave that
up to the platform.
</OL>
The reason this past-the-end addressing was allowed is to make it
easy to write a loop to go over an entire array, e.g.,
while (*d++ = *s++);.
</P>
<P>So, when you think of two pointers delimiting an array, don't think
of them as indexing 0 through n-1. Think of them as <EM>boundary
markers</EM>:
<PRE>
beginning end
| |
| | This is bad. Always having to
| | remember to add or subtract one.
| | Off-by-one bugs very common here.
V V
array of N elements
|---|---|--...--|---|---|
| 0 | 1 | ... |N-2|N-1|
|---|---|--...--|---|---|
^ ^
| |
| | This is good. This is safe. This
| | is guaranteed to work. Just don't
| | dereference 'end'.
beginning end
</PRE>
See? Everything between the boundary markers is part of the array.
Simple.
</P>
<P>Now think back to your junior-high school algebra course, when you
were learning how to draw graphs. Remember that a graph terminating
with a solid dot meant, &quot;Everything up through this point,&quot;
and a graph terminating with an open dot meant, &quot;Everything up
to, but not including, this point,&quot; respectively called closed
and open ranges? Remember how closed ranges were written with
brackets, <EM>[a,b]</EM>, and open ranges were written with parentheses,
<EM>(a,b)</EM>?
</P>
<P>The boundary markers for arrays describe a <EM>half-open range</EM>,
starting with (and including) the first element, and ending with (but
not including) the last element: <EM>[beginning,end)</EM>. See, I
told you it would be simple in the end.
</P>
<P>Iterators, and everything working with iterators, follows this same
time-honored tradition. A container's <TT>begin()</TT> method returns
an iterator referring to the first element, and its <TT>end()</TT>
method returns a past-the-end iterator, which is guaranteed to be
unique and comparable against any other iterator pointing into the
middle of the container.
</P>
<P>Container constructors, container methods, and algorithms, all take
pairs of iterators describing a range of values on which to operate.
All of these ranges are half-open ranges, so you pass the beginning
iterator as the starting parameter, and the one-past-the-end iterator
as the finishing parameter.
</P>
<P>This generalizes very well. You can operate on sub-ranges quite
easily this way; functions accepting a <EM>[first,last)</EM> range
don't know or care whether they are the boundaries of an entire {array,
sequence, container, whatever}, or whether they only enclose a few
elements from the center. This approach also makes zero-length
sequences very simple to recognize: if the two endpoints compare
equal, then the {array, sequence, container, whatever} is empty.
</P>
<P>Just don't dereference <TT>end()</TT>.
</P>
<P>Return <A HREF="#top">to top of page</A> or
<A HREF="../faq/index.html">to the FAQ</A>.
......@@ -85,7 +176,7 @@
<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.1 2000/12/10 04:04:55 pme Exp $
<BR> $Id: howto.html,v 1.2 2001/04/03 00:26:56 pme Exp $
</EM></P>
......
libstdc++-v3/docs/html/25_algorithms/howto.html
......@@ -8,7 +8,7 @@
<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.1 2000/12/10 04:04:55 pme Exp $ -->
<!-- $Id: howto.html,v 1.2 2001/04/03 00:26:56 pme Exp $ -->
</HEAD>
<BODY>
......@@ -37,12 +37,12 @@
important things:
<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. So do your own iterators.
these algorithms. Raw pointers make great candidates, thus
built-in arrays are fine containers. So do your own iterators.
<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.
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
......@@ -59,7 +59,7 @@
<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">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
(it's not that hard, honest!), then the algorithms are a cakewalk.
......@@ -87,7 +87,7 @@
<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.1 2000/12/10 04:04:55 pme Exp $
<BR> $Id: howto.html,v 1.2 2001/04/03 00:26:56 pme Exp $
</EM></P>
......
libstdc++-v3/docs/html/26_numerics/howto.html
......@@ -8,7 +8,7 @@
<META NAME="GENERATOR" CONTENT="vi and eight fingers">
<TITLE>libstdc++-v3 HOWTO: Chapter 26</TITLE>
<LINK REL=StyleSheet HREF="../lib3styles.css">
<!-- $Id: howto.html,v 1.1 2000/12/10 04:04:56 pme Exp $ -->
<!-- $Id: howto.html,v 1.2 2001/04/03 00:26:56 pme Exp $ -->
</HEAD>
<BODY>
......@@ -35,6 +35,7 @@
<LI><A HREF="#1">Complex Number Processing</A>
<LI><A HREF="#2">Array Processing</A>
<LI><A HREF="#3">Numerical Functions</A>
<LI><A HREF="#4">C99</A>
</UL>
<HR>
......@@ -125,6 +126,27 @@
<A HREF="../faq/index.html">to the FAQ</A>.
</P>
<HR>
<H2><A NAME="4">C99</A></H2>
<P>In addition to the other topics on this page, we'll note here some
of the C99 features that appear in libstdc++-v3.
</P>
<P>The C99 features depend on the <TT>--enable-c99</TT> configure flag.
This flag is already on by default, but it can be disabled by the
user. Also, the configuration machinery will disable it if the
neccessary support for C99 (e.g., header files) cannot be found.
</P>
<P>As of GCC 3.0, C99 support includes classification functions
such as <TT>isnormal</TT>, <TT>isgreater</TT>, <TT>isnan</TT>, etc.
The functions used for 'long long' support such as <TT>strtoll</TT>
are supported, as is the <TT>lldiv_t</TT> typedef. Also supported
are the wide character functions using 'long long', like
<TT>wcstoll</TT>.
</P>
<P>Return <A HREF="#top">to top of page</A> or
<A HREF="../faq/index.html">to the FAQ</A>.
</P>
<!-- ####################################################### -->
......@@ -133,7 +155,7 @@
<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.1 2000/12/10 04:04:56 pme Exp $
<BR> $Id: howto.html,v 1.2 2001/04/03 00:26:56 pme Exp $
</EM></P>
......
libstdc++-v3/docs/html/27_io/howto.html
......@@ -8,7 +8,7 @@
<META NAME="GENERATOR" CONTENT="vi and eight fingers">
<TITLE>libstdc++-v3 HOWTO: Chapter 27</TITLE>
<LINK REL=StyleSheet HREF="../lib3styles.css">
<!-- $Id: howto.html,v 1.3 2001/02/07 00:03:21 pme Exp $ -->
<!-- $Id: howto.html,v 1.4 2001/04/03 00:26:56 pme Exp $ -->
</HEAD>
<BODY>
......@@ -26,7 +26,6 @@
<LI><A HREF="#1">Copying a file</A>
<LI><A HREF="#2">The buffering is screwing up my program!</A>
<LI><A HREF="#3">Binary I/O</A>
<LI><A HREF="#4">Iostreams class hierarchy diagram</A>
<LI><A HREF="#5">What is this &lt;sstream&gt;/stringstreams thing?</A>
<LI><A HREF="#6">Deriving a stream buffer</A>
<LI><A HREF="#7">More on binary I/O</A>
......@@ -285,14 +284,6 @@
</P>
<HR>
<H2><A NAME="4">Iostreams class hierarchy diagram</A></H2>
<P>The <A HREF="iostreams_hierarchy.pdf">diagram</A> is in PDF. Rumor
has it that once Benjamin Kosnik has been dead for a few decades,
this work of his will be hung next to the Mona Lisa in the
<A HREF="http://www.louvre.fr/">Musee du Louvre</A>.
</P>
<HR>
<H2><A NAME="5">What is this &lt;sstream&gt;/stringstreams thing?</A></H2>
<P>Stringstreams (defined in the header <TT>&lt;sstream&gt;</TT>)
are in this author's opinion one of the coolest things since
......@@ -416,7 +407,7 @@
<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/02/07 00:03:21 pme Exp $
<BR> $Id: howto.html,v 1.4 2001/04/03 00:26:56 pme Exp $
</EM></P>
......
libstdc++-v3/docs/html/documentation.html
......@@ -3,7 +3,7 @@
<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.2 2001/05/19 20:27:36 pme Exp $ -->
<!-- $Id: documentation.html,v 1.3 2001/05/23 02:00:05 pme Exp $ -->
</HEAD>
<BODY>
......@@ -11,15 +11,42 @@
<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,
for releases and snapshots. The sole exception is the
<A HREF="#4">automatically-generated source documentation</A>,
available separately.
automatically-generated source documentation, available separately.
</P>
<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>
The latest collection is <TT>libstdc++-doxygen-20010501.tar.gz</TT> (3.7MB),
<A HREF="libstdc++-doxygen-20010501/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
almost certainly need to use one of the
<A HREF="http://gcc.gnu.org/mirrors.html">mirror sites</A> to download
the tarball. After unpacking, simply load
libstdc++-doxygen-20010501/index.html <!-- also update this date -->
in a browser. Feedback (and additional documentation!) is welcome.
</P>
<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
implementation of ISO 14882. A brief description follows the name
of the file.
</P>
<P>
<UL>
<LI><A HREF="17_intro/BADNAMES">BADNAMES</A>
- names to avoid because of potential collisions
......@@ -35,8 +62,8 @@
<LI><A HREF="17_intro/HEADER_POLICY">HEADER_POLICY</A>
- header naming and sub-include structure
<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. -->
<!-- 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>
- instructions for building, using
......@@ -46,13 +73,7 @@
<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>
<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>
</P>
<HR>
<H2><A NAME="3">Chapter-Specific Information, Extensions, Notes and Advice</A></H2>
......@@ -71,27 +92,5 @@
<LI><A HREF="ext/howto.html">Extensions to the Standard Library</A>
</OL>
<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>
The latest
collection is libstdc++-doxygen-20010501.tar.gz (3.7MB), available in
the libstdc++ snapshots directory at
<TT>&lt;URL:ftp://gcc.gnu.org/pub/gcc/libstdc++/&gt;</TT>. You will
almost certainly need to use one of the
<A HREF="http://gcc.gnu.org/mirrors.html">mirror sites</A> to download
the tarball. After unpacking, simply load
libstdc++-doxygen-20010501/index.html in a browser. You can also
browse the same collection
<A HREF="libstdc++-doxygen-20010501/index.html">online</A>.
Feedback (and additional documentation!) is welcome.
</P>
</BODY>
</HTML>
libstdc++-v3/docs/html/ext/howto.html
......@@ -8,7 +8,7 @@
<META NAME="GENERATOR" CONTENT="vi and eight fingers">
<TITLE>libstdc++-v3 HOWTO: Extensions</TITLE>
<LINK REL=StyleSheet HREF="../lib3styles.css">
<!-- $Id: howto.html,v 1.3 2001/04/03 00:26:56 pme Exp $ -->
<!-- $Id: howto.html,v 1.4 2001/05/02 01:39:03 pme Exp $ -->
</HEAD>
<BODY>
......@@ -116,14 +116,21 @@
<P>
<UL>
<LI><TT>filebuf</TT>s have another ctor with this signature:<BR>
<TT>basic_filebuf(int __fd, const char* __name, ios_base::openmode __mode);</TT>
<TT>basic_filebuf(__c_file_type*, ios_base::openmode, int_type);</TT>
<BR>This comes in very handy in a number of places, such as
attaching Unix sockets, pipes, and anything else which uses file
descriptors, into the IOStream buffering classes. The three
arguments are as follows:<BR>
<TT>int __fd, </TT>// open file descriptor<BR>
<TT>const char* __name, </TT><BR>
<TT>ios_base::openmode __mode </TT>// same as the other openmode uses
arguments are as follows:
<UL>
<LI><TT>__c_file_type* F </TT>
// the __c_file_type typedef usually boils down to stdio's FILE
<LI><TT>ios_base::openmode M </TT>
// same as all the other uses of openmode
<LI><TT>int_type B </TT>
// buffer size, defaults to BUFSIZ
</UL>
For those wanting to use file descriptors instead of FILE*'s, I
invite you to contemplate the mysteries of C's <TT>fdopen()</TT>.
</UL>
</P>
<P>Return <A HREF="#top">to top of page</A> or
......@@ -159,7 +166,7 @@
<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/04/03 00:26:56 pme Exp $
<BR> $Id: howto.html,v 1.4 2001/05/02 01:39:03 pme Exp $
</EM></P>
......
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