+2002-05-01 Phil Edwards <pme@gcc.gnu.org>
+
+ * include/std/std_bitset.h: Fix doxygen comments.
+ * docs/html/documentation.html: Minor tweaks for 3.1.
+ * docs/html/27_io/howto.html: Likewise.
+ * docs/html/ext/howto.html: Likewise, mention stdio_filebuf.
+ * docs/html/faq/index.html: Likewise.
+ * docs/html/faq/index.txt: Regenerated.
+
2002-05-01 Benjamin Kosnik <bkoz@redhat.com>
PR libstdc++/6533
return 0;
}
</pre>
- Try it yourself!
+ Try it yourself! More examples can be found in 3.1.x code, in
+ <code>include/ext/*_filebuf.h</code>.
</p>
<hr>
The upside is that correctness is ensured. The downside is that
writing through <code>cout</code> can quite easily lead to awful
performance when the C++ I/O library is layered on top of the C I/O
- library (as it is for 3.0 by default). Some patches are in the
- works which should improve the situation for 3.1.
+ library (as it is for 3.0 by default). Some patches have been applied
+ which improve the situation for 3.1.
</p>
<p>However, the C and C++ standard streams only need to be kept in sync
when both libraries' facilities are in use. If your program only uses
</p>
<p>You must do this before performing any I/O via the C++ stream objects.
Once you call this, the C++ streams will operate independently of the
- (unused) C streams. For GCC 3.0, this means that <code>cout</code> and
+ (unused) C streams. For GCC 3.x, this means that <code>cout</code> and
company will become fully buffered on their own.
</p>
<p>Note, by the way, that the synchronization requirement only applies to
</p>
<p>The available user-level collections are also viewable online:
<ul>
- <li><a href="libstdc++-doxygen-3.0/index.html">docs for the 3.0 release</a>
+ <li><a href="libstdc++-doxygen-3.1/index.html">docs for the 3.1 release</a>
<li><a href="libstdc++-html-USERS-3.0.96/index.html">docs for the most
recent libstdc++ snapshot (3.0.96)</a>
<li><a href="latest-doxygen/index.html">"the latest collection"</a>
- (snapshot collection or later; see the date on the first page)
+ (usually the snapshot collection or later; see the date on the first page)
</ul>
Other collections (man pages, maintainer docs) are only available on the
FTP sites.
<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>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>
<a href="sgiexts.html">their own page</a>. Since the SGI STL is no
longer actively maintained, we will try and keep this code working
ourselves.</li>
- <li><code>filebuf</code>s have another ctor with this signature:<br>
+ <li>3.0.x <code>filebuf</code>s have another ctor with this signature:<br>
<code>basic_filebuf(__c_file_type*, ios_base::openmode, int_type);</code>
<br>This comes in very handy in a number of places, such as
attaching Unix sockets, pipes, and anything else which uses file
library cannot track what you do on your own with a file descriptor,
so if you perform any I/O directly, don't expect the library to be
aware of it.
+ <li>Beginning with 3.1, the extra <code>filebuf</code> constructor and
+ the <code>fd()</code> function were removed from the standard
+ filebuf. Instead, <code><ext/stdio_filebuf.h></code> contains
+ a derived class called <code>__gnu_cxx::stdio_filebuf</code>.
</ul>
</p>
<p>Return <a href="#top">to top of page</a> or
(If you decide to be unportable, then you're free do do what you want,
but it's not our fault if stuff breaks.) They are presented here for
information for maintainers and contributors in addition to users, but
- we will probably make them available for users in 3.1 somehow.
+ we will probably make them available for users in 3.2 somehow.
</p>
<p>These classes are always available:
<ul>
has recently been taken over by the
<a href="http://gcc.gnu.org/">GCC team</a>. All of
the rapid development and near-legendary
- <a href="http://gcc.gnu.org/gcc-2.95/buildstat.html">portability</a>
+ <a href="http://gcc.gnu.org/gcc-3.0/buildstat.html">portability</a>
that are the hallmarks of an open-source project are being
applied to libstdc++.
</p>
then you will suddenly be faced with huge numbers of ambiguity
errors. This was discussed on the -v3 list; Nathan Myers
<a href="http://gcc.gnu.org/ml/libstdc++/2001-01/msg00247.html">sums
- things up here</a>.
+ things up here</a>. The collisions with vector/string iterator
+ types have been fixed for 3.1. <!-- more links to email here -->
</p>
</a>
<a name="4_4_interface"><h3>The g++-3 headers are
expansion in container classes and buffer usage in synchronized
stream objects.
</p>
- <li><p>An ABI for libstdc++ will eventually be developed, so that
+ <li><p>An ABI for libstdc++ is being developed, so that
multiple binary-incompatible copies of the library can be replaced
with a single backwards-compatible library, like libgcc_s.so is.
</p>
same namespace as other comparison functions (e.g., 'using' them and
the <iterator> header), then you will suddenly be faced with huge
numbers of ambiguity errors. This was discussed on the -v3 list;
- Nathan Myers [79]sums things up here.
+ Nathan Myers [79]sums things up here. The collisions with
+ vector/string iterator types have been fixed for 3.1.
The g++-3 headers are not ours
already underway for post-3.0 releases, starting with memory
expansion in container classes and buffer usage in synchronized
stream objects.
- 3. An ABI for libstdc++ will eventually be developed, so that
- multiple binary-incompatible copies of the library can be replaced
- with a single backwards-compatible library, like libgcc_s.so is.
+ 3. An ABI for libstdc++ is being developed, so that multiple
+ binary-incompatible copies of the library can be replaced with a
+ single backwards-compatible library, like libgcc_s.so is.
4. The current libstdc++ contains extensions to the Library which
must be explicitly requested by client code (for example, the hash
tables from SGI). Other extensions may be added to libstdc++-v3 if
50. ../faq/index.html#4_4_interface
51. ../17_intro/DESIGN
52. http://gcc.gnu.org/
- 53. http://gcc.gnu.org/gcc-2.95/buildstat.html
+ 53. http://gcc.gnu.org/gcc-3.0/buildstat.html
54. http://gcc.gnu.org/libstdc++/
55. http://gcc.gnu.org/libstdc++/download.html
56. http://gcc.gnu.org/libstdc++/
*
* @ingroup Containers
*
- * Meets the requirements of a <a href="tables.html#65">container</a>.
+ * (Note that %bitset does @e not meet the formal requirements of a
+ * <a href="tables.html#65">container</a>. Mainly, it lacks iterators.)
*
* The template argument, @a _Nb, may be any nonzero number of type
* size_t.
/**
* @brief Finds the index of the first "on" bit.
+ * @return The index of the first bit set, or size() if not found.
* @ingroup SGIextensions
* @sa _Find_next
*/
/**
* @brief Finds the index of the next "on" bit after prev.
+ * @return The index of the next bit set, or size() if not found.
* @param prev Where to start searching.
* @ingroup SGIextensions
* @sa _Find_first