Commit 17e7554f by Felix Natter Committed by Phil Edwards

porting-howto.html: Fixed some errors.

2001-06-26  Felix Natter  <f.natter@ndh.net>

	* docs/html/17_intro/porting-howto.html:  Fixed some errors.

From-SVN: r43582
parent f68fc4db
2001-06-26 Felix Natter <f.natter@ndh.net>
* docs/html/17_intro/porting-howto.html: Fixed some errors.
2001-06-26 Benjamin Kosnik <bkoz@redhat.com> 2001-06-26 Benjamin Kosnik <bkoz@redhat.com>
* include/bits/stl_iterator.h (istream_iterator::operator->): Fix * include/bits/stl_iterator.h (istream_iterator::operator->): Fix
......
<!DOCTYPE HTML PUBLIC "http://www.w3.org/TR/REC-html40/loose.dtd" "-//W3C//DTD HTML 4.0 Transitional//EN">
<html> <html>
<head> <head>
<title>Libstdc++-porting-howto</title> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<meta content="DocBook XSL Stylesheets V1.16" name="generator"> <title>Libstdc++-porting-howto</title>
</head> <meta name="generator" content="DocBook XSL Stylesheets V1.29">
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> </head>
<div class="article" id="libstdporting"> <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div id="libstdc++-porting" class="article">
<div class="titlepage"> <div class="titlepage">
<h1 class="title"> <div><h1 class="title">
<a name="libstdporting">Libstdc++-porting-howto</a> <a name="libstdc++-porting"></a>Libstdc++-porting-howto</h1></div>
</h1> <div><h3 class="author">Felix Natter</h3></div>
<h3 class="author">Felix Natter</h3> <div><div class="legalnotice">
<p> <p class="legalnotice-title"><b>Legal Notice</b></p>
<p>
This document can be distributed under the FDL This document can be distributed under the FDL
(<a href="http://www.gnu.org">www.gnu.org</a>) (<a href="http://www.gnu.org" target="_top">www.gnu.org</a>)
</p> </p>
<p class="pubdate">what kind of a date ? I don't drink !</p> </div></div>
<div class="revhistory"> <div><p class="pubdate">Tue Jun 5 20:07:49 2001</p></div>
<table width="100%" border="1"> <div><div class="revhistory"><table border="1" width="100%" summary="Revision history">
<tr> <tr><th align="left" valign="top" colspan="3"><b>Revision History</b></th></tr>
<th colspan="3" valign="top" align="left"><b>Revision History</b></th> <tr>
</tr> <td align="left">Revision 0.5</td>
<tr> <td align="left">Thu Jun 1 13:06:50 2000</td>
<td align="left">Revision 0.5</td><td align="left">Thu Jun 1 13:06:50 2000</td><td align="left">fnatter</td> <td align="left">fnatter</td>
</tr> </tr>
<tr> <tr><td align="left" colspan="3">First docbook-version.</td></tr>
<td colspan="3" align="left">First docbook-version.</td> <tr>
</tr> <td align="left">Revision 0.8</td>
<tr> <td align="left">Sun Jul 30 20:28:40 2000</td>
<td align="left">Revision 0.8</td><td align="left">Sun Jul 30 20:28:40 2000</td><td align="left">fnatter</td> <td align="left">fnatter</td>
</tr> </tr>
<tr> <tr><td align="left" colspan="3">First released version using docbook-xml
<td colspan="3" align="left">First released version using docbook-xml
+ second upload to libstdc++-page. + second upload to libstdc++-page.
</td> </td></tr>
</tr> <tr>
<tr> <td align="left">Revision 0.9</td>
<td align="left">Revision 0.9</td><td align="left">Wed Sep 6 02:59:32 2000</td><td align="left">fnatter</td> <td align="left">Wed Sep 6 02:59:32 2000</td>
</tr> <td align="left">fnatter</td>
<tr> </tr>
<td colspan="3" align="left">5 new sections.</td> <tr><td align="left" colspan="3">5 new sections.</td></tr>
</tr> <tr>
</table> <td align="left">Revision 0.9.1</td>
</div> <td align="left">Sat Sep 23 14:20:15 2000</td>
<div class="abstract"> <td align="left">fnatter</td>
<p> </tr>
<a name="N2688"></a><b>Abstract</b> <tr><td align="left" colspan="3">added information about why file-descriptors are not in the
</p> standard</td></tr>
<p> <tr>
<td align="left">Revision 0.9.2</td>
<td align="left">Tue Jun 5 20:07:49 2001</td>
<td align="left">fnatter</td>
</tr>
<tr><td align="left" colspan="3">
a fix, added hint on increased portability of C-shadow-headers,
added autoconf-test HAVE_CONTAINER_AT
</td></tr>
</table></div></div>
<div><div class="abstract">
<p>
<a name="id2715202"></a>
<b>Abstract</b>
</p>
<p>
Some notes on porting applications from libstdc++-2.90 (or earlier Some notes on porting applications from libstdc++-2.90 (or earlier
versions) to libstdc++-v3. Not speaking in terms of the GNU libstdc++ versions) to libstdc++-v3. Not speaking in terms of the GNU libstdc++
implementations, this means porting from earlier versions of the implementations, this means porting from earlier versions of the
C++-Standard to ISO 14882. C++-Standard to ISO 14882.
</p> </p>
</div> </div></div>
<hr> <hr>
</div> </div>
<div class="toc"> <div class="toc">
<p> <p><b>Table of Contents</b></p>
<b>Table of Contents</b> <dl>
</p> <dt>1. <a href="#sec-nsstd">Namespace std::</a>
<dl> </dt>
<dt>1. <a href="#sec-nsstd">Namespace std::</a> <dd><dl>
</dt> <dt>1.1.1. <a href="#sec-gtkmm-hack">Using <i>namespace
<dd>
<dl>
<dt>1.1.1. <a href="#sec-gtkmm-hack">Using <i>namespace
composition</i> if the project uses a separate composition</i> if the project uses a separate
namespace</a> namespace</a>
</dt> </dt>
<dt>1.1.2. <a href="#sec-emptyns">Defining an empty namespace std</a> <dt>1.1.2. <a href="#sec-emptyns">Defining an empty namespace std</a>
</dt> </dt>
<dt>1.1.3. <a href="#sec-avoidfqn">Avoid to use fully qualified names <dt>1.1.3. <a href="#sec-avoidfqn">Avoid to use fully qualified names
(i.e. std::string)</a> (i.e. std::string)</a>
</dt> </dt>
<dt>1.1.4. <a href="#sec-osprojects">How some open-source-projects deal <dt>1.1.4. <a href="#sec-osprojects">How some open-source-projects deal
with this</a> with this</a>
</dt> </dt>
</dl> </dl></dd>
</dd> <dt>2. <a href="#sec-nocreate">there is no ios::nocreate/ios::noreplace
<dt>2. <a href="#sec-nocreate">there is no ios::nocreate/ios::noreplace
in ISO 14882</a> in ISO 14882</a>
</dt> </dt>
<dt>3. <a href="#sec-stream::attach"><b>stream::attach(int <dt>3. <a href="#sec-stream::attach">
<b>stream::attach(int
fd)</b> is not in the standard any more</a> fd)</b> is not in the standard any more</a>
</dt> </dt>
<dt>4. <a href="#sec-headers">The new headers</a> <dt>4. <a href="#sec-headers">The new headers</a>
</dt> </dt>
<dd> <dd><dl>
<dl> <dt>4.4.1. <a href="#sec-cheaders">New headers replacing C-headers</a>
<dt>4.4.1. <a href="#sec-cheaders">New headers replacing C-headers</a> </dt>
</dt> <dt>4.4.2. <a href="#sec-fstream-header">
<dt>4.4.2. <a href="#sec-fstream-header">
<tt>&lt;fstream&gt;</tt> does <tt>&lt;fstream&gt;</tt> does
not define <b>std::cout</b>, not define <b>std::cout</b>,
<b>std::cin</b> etc.</a> <b>std::cin</b> etc.</a>
</dt> </dt>
</dl> </dl></dd>
</dd> <dt>5. <a href="#sec-iterators">Iterators</a>
<dt>5. <a href="#sec-iterators">Iterators</a> </dt>
</dt> <dt>6. <a href="#sec-macros">
<dt>6. <a href="#sec-macros">
Libc-macros (i.e. <b>isspace</b> from Libc-macros (i.e. <b>isspace</b> from
<tt>&lt;cctype&gt;</tt>)</a> <tt>&lt;cctype&gt;</tt>)</a>
</dt> </dt>
<dt>7. <a href="#sec-stream-state"> <dt>7. <a href="#sec-stream-state">
State of streams State of streams
</a> </a>
</dt> </dt>
<dt>8. <a href="#sec-vector-at">vector::at is missing (i.e. gcc 2.95.2)</a> <dt>8. <a href="#sec-vector-at">vector::at is missing (i.e. gcc 2.95.x)</a>
</dt> </dt>
<dt>9. <a href="#sec-eof">Using std::char_traits&lt;char&gt;::eof()</a> <dt>9. <a href="#sec-eof">Using std::char_traits&lt;char&gt;::eof()</a>
</dt> </dt>
<dt>10. <a href="#sec-string-clear">Using string::clear()/string::erase()</a> <dt>10. <a href="#sec-string-clear">Using string::clear()/string::erase()</a>
</dt> </dt>
<dt>11. <a href="#sec-stringstream">Using stringstream's</a> <dt>11. <a href="#sec-stringstream">Using stringstream's</a>
</dt> </dt>
<dt>12. <a href="#sec-about">About...</a> <dt>12. <a href="#sec-about">About...</a>
</dt> </dt>
</dl> </dl>
</div> </div>
<p> <p>
In the following, when I say portable, I will refer to "portable among ISO In the following, when I say portable, I will refer to &quot;portable among ISO
14882-implementations". On the other hand, if I say "backportable" or 14882-implementations&quot;. On the other hand, if I say &quot;backportable&quot; or
"conservative", I am talking about "compiles with older &quot;conservative&quot;, I am talking about &quot;compiles with older
libstdc++-implementations". libstdc++-implementations&quot;.
</p> </p>
<div class="section" id="sec-nsstd"> <div class="section">
<h2 class="title" style="clear: all"> <a name="sec-nsstd"></a>
<a name="sec-nsstd"><b>1. Namespace std::</b></a> <div class="titlepage"><div><h2 class="title" style="clear: all">
</h2> <a name="sec-nsstd"></a>
<p> <span class="label">1.</span> <span class="title">Namespace std::</span>
</h2></div></div>
<p>
The latest C++-standard (ISO-14882) requires that the standard The latest C++-standard (ISO-14882) requires that the standard
C++-library is defined in namespace std::. Thus, in order to use C++-library is defined in namespace std::. Thus, in order to use
classes from the standard C++-library, you can do one of three classes from the standard C++-library, you can do one of three
things: things:
<div class="itemizedlist"> <div class="itemizedlist"><ul>
<ul> <li><p>
<li> <a name="id2715113"></a>wrap your code in <b>namespace std {
<a name="N2712"></a>
<p>wrap your code in <b>namespace std {
... }</b> =&gt; This is not an option because only symbols ... }</b> =&gt; This is not an option because only symbols
from the standard c++-library are defined in namespace std::. from the standard c++-library are defined in namespace std::.
</p> </p></li>
</li> <li><p>
<li> <a name="id2668711"></a>put a kind of
<a name="N2721"></a>
<p>put a kind of
<i>using-declaration</i> in your source (either <i>using-declaration</i> in your source (either
<b>using namespace std;</b> or i.e. <b>using <b>using namespace std;</b> or i.e. <b>using
std::string;</b>) =&gt; works well for source-files, but std::string;</b>) =&gt; works well for source-files, but
cannot be used in header-files. cannot be used in header-files.
</p> </p></li>
</li> <li><p>
<li> <a name="id2668731"></a>use a <i>fully qualified name</i> for
<a name="N2736"></a>
<p>use a <i>fully qualified name</i> for
each libstdc++-symbol (i.e. <b>std::string</b>, each libstdc++-symbol (i.e. <b>std::string</b>,
<b>std::cout</b>) =&gt; can always be used <b>std::cout</b>) =&gt; can always be used
</p></li>
</ul></div>
</p> </p>
</li> <p>
</ul>
</div>
</p>
<p>
Because there are many compilers which still use an implementation Because there are many compilers which still use an implementation
that does not have the standard C++-library in namespace that does not have the standard C++-library in namespace
<b>std::</b>, some care is required to support these as <b>std::</b>, some care is required to support these as
well. well.
</p> </p>
<p> <p>
Namespace back-portability-issues are generally not a problem with Namespace back-portability-issues are generally not a problem with
g++, because versions of g++ that do not have libstdc++ in g++, because versions of g++ that do not have libstdc++ in
<b>std::</b> use <b>-fno-honor-std</b> <b>std::</b> use <b>-fno-honor-std</b>
...@@ -178,18 +183,20 @@ ...@@ -178,18 +183,20 @@
to care about it. This probably applies to some other compilers as to care about it. This probably applies to some other compilers as
well. well.
</p> </p>
<p> <p>
The following sections list some possible solutions to support compilers The following sections list some possible solutions to support compilers
that cannot ignore std::. that cannot ignore std::.
</p> </p>
<div class="section" id="sec-gtkmm-hack"> <div class="section">
<h3 class="title"> <a name="sec-gtkmm-hack"></a>
<a name="sec-gtkmm-hack"><b>1.1.1. Using <i>namespace <div class="titlepage"><div><h3 class="title">
<a name="sec-gtkmm-hack"></a>
<span class="label">1.1.1.</span> <span class="title">Using <i>namespace
composition</i> if the project uses a separate composition</i> if the project uses a separate
namespace</b></a> namespace</span>
</h3> </h3></div></div>
<p> <p>
<a href="http://gtkmm.sourceforge.net">Gtk--</a> defines <a href="http://gtkmm.sourceforge.net" target="_top">Gtk--</a> defines
most of its classes in namespace Gtk::. Thus, it was possible to most of its classes in namespace Gtk::. Thus, it was possible to
adapt Gtk-- to namespace std:: by using a C++-feature called adapt Gtk-- to namespace std:: by using a C++-feature called
<i>namespace composition</i>. This is what happens if <i>namespace composition</i>. This is what happens if
...@@ -210,18 +217,20 @@ ...@@ -210,18 +217,20 @@
<b>using namespace Gtk;</b> (which is not recommended <b>using namespace Gtk;</b> (which is not recommended
practice for Gtk--, so it is not a problem). Additionally, the practice for Gtk--, so it is not a problem). Additionally, the
<b>using</b>-declarations are wrapped in macros that <b>using</b>-declarations are wrapped in macros that
are set based on autoconf-tests to either "" or i.e. <b>using are set based on autoconf-tests to either &quot;&quot; or i.e. <b>using
std::string;</b> (depending on whether the system has std::string;</b> (depending on whether the system has
libstdc++ in <b>std::</b> or not). (ideas from libstdc++ in <b>std::</b> or not). (ideas from
<tt>&lt;<a href="mailto:llewelly@dbritsch.dsl.xmission.com">llewelly@dbritsch.dsl.xmission.com</a>&gt;</tt>, Karl Nelson <tt>&lt;<a href="mailto:llewelly@dbritsch.dsl.xmission.com">llewelly@dbritsch.dsl.xmission.com</a>&gt;</tt>, Karl Nelson
<tt>&lt;<a href="mailto:kenelson@ece.ucdavis.edu">kenelson@ece.ucdavis.edu</a>&gt;</tt>) <tt>&lt;<a href="mailto:kenelson@ece.ucdavis.edu">kenelson@ece.ucdavis.edu</a>&gt;</tt>)
</p> </p>
</div> </div>
<div class="section" id="sec-emptyns"> <div class="section">
<h3 class="title"> <a name="sec-emptyns"></a>
<a name="sec-emptyns"><b>1.1.2. Defining an empty namespace std</b></a> <div class="titlepage"><div><h3 class="title">
</h3> <a name="sec-emptyns"></a>
<p> <span class="label">1.1.2.</span> <span class="title">Defining an empty namespace std</span>
</h3></div></div>
<p>
By defining an (empty) namespace <b>std::</b> before By defining an (empty) namespace <b>std::</b> before
using it, you avoid getting errors on systems where no part of the using it, you avoid getting errors on systems where no part of the
library is in namespace std: library is in namespace std:
...@@ -230,106 +239,122 @@ ...@@ -230,106 +239,122 @@
using namespace std; using namespace std;
</pre> </pre>
</p> </p>
</div> </div>
<div class="section" id="sec-avoidfqn"> <div class="section">
<h3 class="title"> <a name="sec-avoidfqn"></a>
<a name="sec-avoidfqn"><b>1.1.3. Avoid to use fully qualified names <div class="titlepage"><div><h3 class="title">
(i.e. std::string)</b></a> <a name="sec-avoidfqn"></a>
</h3> <span class="label">1.1.3.</span> <span class="title">Avoid to use fully qualified names
<p> (i.e. std::string)</span>
</h3></div></div>
<p>
If some compilers complain about <b>using If some compilers complain about <b>using
std::string;</b>, and if the "hack" for gtk-- mentioned above std::string;</b>, and if the &quot;hack&quot; for gtk-- mentioned above
does not work, then it might be a good idea to define a macro does not work, then it might be a good idea to define a macro
NS_STD, which is defined to either "" or "std" NS_STD, which is defined to either &quot;&quot; or &quot;std&quot;
based on an autoconf-test. Then you should be able to use based on an autoconf-test. Then you should be able to use
<b>NS_STD::string</b>, which will evaluate to <b>NS_STD::string</b>, which will evaluate to
<b>::string</b> ("string in the global namespace") on <b>::string</b> (&quot;string in the global namespace&quot;) on
systems that do not put string in std::. (This is untested) systems that do not put string in std::. (This is untested)
</p> </p>
</div> </div>
<div class="section" id="sec-osprojects"> <div class="section">
<h3 class="title"> <a name="sec-osprojects"></a>
<a name="sec-osprojects"><b>1.1.4. How some open-source-projects deal <div class="titlepage"><div><h3 class="title">
with this</b></a> <a name="sec-osprojects"></a>
</h3> <span class="label">1.1.4.</span> <span class="title">How some open-source-projects deal
<p> with this</span>
</h3></div></div>
<p>
This information was gathered around May 2000. It may not be correct This information was gathered around May 2000. It may not be correct
by the time you read this. by the time you read this.
</p> </p>
<div class="table"> <div class="table">
<p> <p>
<a name="N2901"></a><b>Table 1. Namespace std:: in Open-Source programs</b> <a name="id2668681"></a>
</p> <b>Table 1. Namespace std:: in Open-Source programs</b>
<table border="1"> </p>
<colgroup> <table summary="Namespace std:: in Open-Source programs" border="1">
<col> <colgroup>
<col> <col>
</colgroup> <col>
<tbody> </colgroup>
<tr> <tbody>
<td><a href="http://www.clanlib.org">clanlib</a></td><td>usual</td> <tr>
</tr> <td><a href="http://www.clanlib.org" target="_top">clanlib</a></td>
<tr> <td>usual</td>
<td><a href="http://pingus.seul.org">pingus</a></td><td>usual</td> </tr>
</tr> <tr>
<tr> <td><a href="http://pingus.seul.org" target="_top">pingus</a></td>
<td><a href="http://www.mozilla.org">mozilla</a></td><td>usual</td> <td>usual</td>
</tr> </tr>
<tr> <tr>
<td><a href="http://www.mnemonic.org">mnemonic</a></td><td>none</td> <td><a href="http://www.mozilla.org" target="_top">mozilla</a></td>
</tr> <td>usual</td>
<tr> </tr>
<td><a href="http://libsigc.sourceforge.net"> <tr>
libsigc++</a></td><td>conservative-impl</td> <td><a href="http://www.mnemonic.org" target="_top">mnemonic</a></td>
</tr> <td>none</td>
</tbody> </tr>
</table> <tr>
</div> <td><a href="http://libsigc.sourceforge.net" target="_top">
<div class="table"> libsigc++</a></td>
<p> <td>conservative-impl</td>
<a name="N2978"></a><b>Table 2. Notations for categories</b> </tr>
</p> </tbody>
<table border="1"> </table>
<colgroup> </div>
<col> <div class="table">
<col> <p>
</colgroup> <a name="id2666288"></a>
<tbody> <b>Table 2. Notations for categories</b>
<tr> </p>
<td>usual</td><td>mostly fully qualified names and some <table summary="Notations for categories" border="1">
<colgroup>
<col>
<col>
</colgroup>
<tbody>
<tr>
<td>usual</td>
<td>mostly fully qualified names and some
using-declarations (but not in headers)</td> using-declarations (but not in headers)</td>
</tr> </tr>
<tr> <tr>
<td>none</td><td>no namespace std at all</td> <td>none</td>
</tr> <td>no namespace std at all</td>
<tr> </tr>
<td>conservative-impl</td><td>wrap all <tr>
<td>conservative-impl</td>
<td>wrap all
namespace-handling in macros to support compilers without namespace-handling in macros to support compilers without
namespace-support (no libstdc++ used in headers)</td> namespace-support (no libstdc++ used in headers)</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</div> </div>
<p> <p>
As you can see, this currently lacks an example of a project which As you can see, this currently lacks an example of a project which
uses libstdc++-symbols in headers in a back-portable way (except uses libstdc++-symbols in headers in a back-portable way (except
for Gtk--: see the <a href="#"></a>). for Gtk--: see the <a href="#sec-gtkmm-hack"></a>).
</p> </p>
</div> </div>
</div> </div>
<div class="section" id="sec-nocreate"> <div class="section">
<h2 class="title" style="clear: all"> <a name="sec-nocreate"></a>
<a name="sec-nocreate"><b>2. there is no ios::nocreate/ios::noreplace <div class="titlepage"><div><h2 class="title" style="clear: all">
in ISO 14882</b></a> <a name="sec-nocreate"></a>
</h2> <span class="label">2.</span> <span class="title">there is no ios::nocreate/ios::noreplace
<p> in ISO 14882</span>
I have seen <b>ios::nocreate</b> being used for input-streams, </h2></div></div>
most probably because the authors thought it would be more correct <p>
to specify nocreate "explicitly". So you can simply leave it out I have seen <b>ios::nocreate</b> being used for
for input-streams. input-streams, most probably because the author thought it would be
</p> more correct to specify nocreate &quot;explicitly&quot;. So you can simply
<p> leave it out for input-streams.
For output streams, "nocreate" is probably the default, unless you </p>
<p>
For output streams, &quot;nocreate&quot; is probably the default, unless you
specify <b>std::ios::trunc</b> ? To be safe, you can open specify <b>std::ios::trunc</b> ? To be safe, you can open
the file for reading, check if it has been opened, and then decide the file for reading, check if it has been opened, and then decide
whether you want to create/replace or not. To my knowledge, even whether you want to create/replace or not. To my knowledge, even
...@@ -337,137 +362,158 @@ ...@@ -337,137 +362,158 @@
<b>ate</b> and <b>trunc</b> (except for <b>ate</b> and <b>trunc</b> (except for
<b>app</b> ?). <b>app</b> ?).
</p> </p>
</div> </div>
<div class="section" id="sec-stream::attach"> <div class="section">
<h2 class="title" style="clear: all"> <a name="sec-stream::attach"></a>
<a name="sec-stream::attach"><b>3. <b>stream::attach(int <div class="titlepage"><div><h2 class="title" style="clear: all">
fd)</b> is not in the standard any more</b></a> <a name="sec-stream::attach"></a>
</h2> <span class="label">3.</span> <span class="title">
<p> <b>stream::attach(int
fd)</b> is not in the standard any more</span>
</h2></div></div>
<p>
Phil Edwards <tt>&lt;<a href="mailto:pedwards@disaster.jaj.com">pedwards@disaster.jaj.com</a>&gt;</tt> writes:
It was considered and rejected. Not all environments use file
descriptors. Of those that do, not all of them use integers to represent
them.
</p>
<p>
When using libstdc++-v3, you can use When using libstdc++-v3, you can use
<div id="N3082" class="funcsynopsis"> <div class="funcsynopsis" id="id2666593">
<p> <p>
</p> <a name="id2666593"></a>
<a name="N3082"></a> <pre class="funcsynopsisinfo">
<pre class="funcsynopsisinfo">
#include &lt;fstream&gt; #include &lt;fstream&gt;
</pre> </pre>
<p> <p><code>
<code><code class="funcdef">int <b class="fsfunc">basic_filebuf</b></code>(<var class="pdparam">__fd</var>, <var class="pdparam">__name</var>, <var class="pdparam">__mode</var>);<br>int <var class="pdparam">__fd</var>;<br>const char* <var class="pdparam">__name</var>;<br>ios_base::openmode <var class="pdparam">__mode</var>;</code> <code class="funcdef">int <b class="fsfunc">basic_filebuf</b>
</p> </code>(<var class="pdparam">__fd</var>, <var class="pdparam">__name</var>, <var class="pdparam">__mode</var>);<br>int <var class="pdparam">__fd</var>;<br>const char* <var class="pdparam">__name</var>;<br>ios_base::openmode <var class="pdparam">__mode</var>;</code></p>
<p> <p>
</p> </div>
</div> but the the signature of this constructor has changed often, and
For a portable solution (if there is one), you need to implement a it might change again.
subclass of <b>streambuf</b> which opens a file given a For a portable solution (among systems which use
descriptor, and then pass an instance of this to the filedescriptors), you need to implement a subclass of
<b>streambuf</b> (or
<b>basic_streambuf&lt;..&gt;</b>) which opens a file
given a descriptor, and then pass an instance of this to the
stream-constructor (from the Josuttis-book). stream-constructor (from the Josuttis-book).
</p> </p>
</div> </div>
<div class="section" id="sec-headers"> <div class="section">
<h2 class="title" style="clear: all"> <a name="sec-headers"></a>
<a name="sec-headers"><b>4. The new headers</b></a> <div class="titlepage"><div><h2 class="title" style="clear: all">
</h2> <a name="sec-headers"></a>
<p> <span class="label">4.</span> <span class="title">The new headers</span>
All new headers can be seen in this <a href="../../testsuite/17_intro/headers.cc">source-code</a>. </h2></div></div>
</p> <p>
<p> All new headers can be seen in this <a href="headers_cc.txt" target="_top">
I think it is a problem for libstdc++-v3 to add links or wrappers source-code</a>.
for the old headers, because the implementation has changed, and </p>
the header name-changes indicate this. It might be preferable to <p>
use the new headers and tell users of old compilers that they The old C++-headers (iostream.h etc.) are available, but gcc generates
should create links (which is what they will have to do sometime a warning that you are using deprecated headers.
anyway). </p>
</p> <div class="section">
<div class="section" id="sec-cheaders"> <a name="sec-cheaders"></a>
<h3 class="title"> <div class="titlepage"><div><h3 class="title">
<a name="sec-cheaders"><b>4.4.1. New headers replacing C-headers</b></a> <a name="sec-cheaders"></a>
</h3> <span class="label">4.4.1.</span> <span class="title">New headers replacing C-headers</span>
<p> </h3></div></div>
You should not use the C-headers (except for system-level headers) <p>
from C++ programs. Instead, you should use a set of headers that You should not use the C-headers (except for system-level
are named by prepending 'c' and, as usual, ommiting the extension headers) from C++ programs. Instead, you should use a set of
(.h). For example, instead of using <tt>&lt;math.h&gt;</tt>, you should use <tt>&lt;cmath&gt;</tt>. The standard headers that are named by prepending 'c' and, as usual,
specifies that if you include the C-style header (<tt>&lt;math.h&gt;</tt> in this case), the symbols omitting the extension (.h). For example, instead of using
will be available both in the global namespace and in namespace <tt>&lt;math.h&gt;</tt>, you
<b>std::</b> (libstdc++-v3, version 2.90.8 currently should use <tt>&lt;cmath&gt;</tt>. In some cases this has
puts them in <b>std::</b> only) On the other hand, if the advantage that the C++-header is more standardized than
you include only the new header (i.e. <tt>&lt;pcmath&gt;</tt>), the symbols will only be the C-header (i.e. <tt>&lt;ctime&gt;</tt> (almost)
defined in namespace <b>std::</b> (and macros will be corresponds to either <tt>&lt;time.h&gt;</tt> or <tt>&lt;sys/time.h&gt;</tt>).
converted to inline-functions).
</p> The standard specifies that if you include the C-style header
<p> (<tt>&lt;math.h&gt;</tt> in
For more information on this, and for information on how the GNU this case), the symbols will be available both in the global
C++ implementation reuses ("shadows") the C library-functions, have namespace and in namespace <b>std::</b> (but
a look at <a href="http://www.cantrip.org/cheaders.html"> libstdc++ does not yet have fully compliant headers) On the
other hand, if you include only the new header (i.e. <tt>&lt;cmath&gt;</tt>), the symbols
will only be defined in namespace <b>std::</b>
(and macros will be converted to inline-functions).
</p>
<p>
For more information on this, and for information on how the
GNU C++ implementation might reuse (&quot;shadow&quot;) the C
library-functions, have a look at <a href="http://www.cantrip.org/cheaders.html" target="_top">
www.cantrip.org</a>. www.cantrip.org</a>.
</p> </p>
</div> </div>
<div class="section" id="sec-fstream-header"> <div class="section">
<h3 class="title"> <a name="sec-fstream-header"></a>
<a name="sec-fstream-header"><b>4.4.2. <div class="titlepage"><div><h3 class="title">
<a name="sec-fstream-header"></a>
<span class="label">4.4.2.</span> <span class="title">
<tt>&lt;fstream&gt;</tt> does <tt>&lt;fstream&gt;</tt> does
not define <b>std::cout</b>, not define <b>std::cout</b>,
<b>std::cin</b> etc.</b></a> <b>std::cin</b> etc.</span>
</h3> </h3></div></div>
<p> <p>
In previous versions of the standard, <tt>&lt;fstream.h&gt;</tt>, <tt>&lt;ostream.h&gt;</tt> and <tt>&lt;istream.h&gt;</tt> used to define In earlier versions of the standard,
<tt>&lt;fstream.h&gt;</tt>,
<tt>&lt;ostream.h&gt;</tt>
and <tt>&lt;istream.h&gt;</tt>
used to define
<b>cout</b>, <b>cin</b> and so on. Because <b>cout</b>, <b>cin</b> and so on. Because
of the templatized iostreams in libstdc++-v3, you need to include of the templatized iostreams in libstdc++-v3, you need to include
<tt>&lt;iostream&gt;</tt> <tt>&lt;iostream&gt;</tt>
explicitly to define these. explicitly to define these.
</p> </p>
</div> </div>
</div> </div>
<div class="section" id="sec-iterators"> <div class="section">
<h2 class="title" style="clear: all"> <a name="sec-iterators"></a>
<a name="sec-iterators"><b>5. Iterators</b></a> <div class="titlepage"><div><h2 class="title" style="clear: all">
</h2> <a name="sec-iterators"></a>
<p> <span class="label">5.</span> <span class="title">Iterators</span>
</h2></div></div>
<p>
The following are not proper uses of iterators, but may be working The following are not proper uses of iterators, but may be working
fixes for existing uses of iterators. fixes for existing uses of iterators.
<div class="itemizedlist"> <div class="itemizedlist"><ul>
<ul> <li><p>
<li> <a name="id2664787"></a>you cannot do
<a name="N3282"></a>
<p>you cannot do
<b>ostream::operator&lt;&lt;(iterator)</b> to <b>ostream::operator&lt;&lt;(iterator)</b> to
print the address of the iterator =&gt; use print the address of the iterator =&gt; use
<b>operator&lt;&lt; &amp;*iterator</b> instead ? <b>operator&lt;&lt; &amp;*iterator</b> instead ?
</p> </p></li>
</li> <li><p>
<li> <a name="id2664753"></a>you cannot clear an iterator's reference
<a name="N3303"></a>
<p>you cannot clear an iterator's reference
(<b>iterator = 0</b>) =&gt; use (<b>iterator = 0</b>) =&gt; use
<b>iterator = iterator_type();</b> ? <b>iterator = iterator_type();</b> ?
</p> </p></li>
</li> <li><p>
<li> <a name="id2664806"></a>
<a name="N3316"></a> <b>if (iterator)</b> won't work any
<p>
<b>if (iterator)</b> won't work any
more =&gt; use <b>if (iterator != iterator_type())</b> more =&gt; use <b>if (iterator != iterator_type())</b>
?</p> ?</p></li>
</li> </ul></div>
</ul> </p>
</div> </div>
</p> <div class="section">
</div> <a name="sec-macros"></a>
<div class="section" id="sec-macros"> <div class="titlepage"><div><h2 class="title" style="clear: all">
<h2 class="title" style="clear: all"> <a name="sec-macros"></a>
<a name="sec-macros"><b>6. <span class="label">6.</span> <span class="title">
Libc-macros (i.e. <b>isspace</b> from Libc-macros (i.e. <b>isspace</b> from
<tt>&lt;cctype&gt;</tt>)</b></a> <tt>&lt;cctype&gt;</tt>)</span>
</h2> </h2></div></div>
<p> <p>
Glibc 2.0.x and 2.1.x define the <tt>&lt;ctype.h&gt;</tt> -functionality as Glibc 2.0.x and 2.1.x define the <tt>&lt;ctype.h&gt;</tt> -functionality as
macros (isspace, isalpha etc.). Libstdc++-v3 "shadows" these macros macros (isspace, isalpha etc.). Libstdc++-v3 &quot;shadows&quot; these macros
as described in the <a href="#"></a>. as described in the <a href="#sec-cheaders"></a>.
</p> </p>
<p> <p>
Older implementations of libstdc++ (g++-2 for egcs 1.x and g++-3 Older implementations of libstdc++ (g++-2 for egcs 1.x and g++-3
for gcc 2.95.2), however, keep these functions as macros, and so it for gcc 2.95.x), however, keep these functions as macros, and so it
is not back-portable to use fully qualified names. For example: is not back-portable to use fully qualified names. For example:
<pre class="programlisting"> <pre class="programlisting">
#include &lt;cctype&gt; #include &lt;cctype&gt;
...@@ -479,14 +525,14 @@ ...@@ -479,14 +525,14 @@
_ISspace ) ; _ISspace ) ;
</pre> </pre>
</p> </p>
<p> <p>
One solution I can think of is to test for -v3 using One solution I can think of is to test for -v3 using
autoconf-macros, and define macros for each of the C-functions autoconf-macros, and define macros for each of the C-functions
(maybe that is possible with one "wrapper" macro as well ?). (maybe that is possible with one &quot;wrapper&quot; macro as well ?).
</p> </p>
<p> <p>
Another solution which would fix g++ is to tell the user to modify a Another solution which would fix g++ is to tell the user to modify a
header-file so that g++-2 (egcs 1.x) and g++-3 (gcc 2.95.2) define a header-file so that g++-2 (egcs 1.x) and g++-3 (gcc 2.95.x) define a
macro which tells <tt>&lt;ctype.h&gt;</tt> to define functions macro which tells <tt>&lt;ctype.h&gt;</tt> to define functions
instead of macros: instead of macros:
<pre class="programlisting"> <pre class="programlisting">
...@@ -498,7 +544,7 @@ ...@@ -498,7 +544,7 @@
[ now include &lt;ctype.h&gt; ] [ now include &lt;ctype.h&gt; ]
</pre> </pre>
</p> </p>
<p> <p>
Another problem arises if you put a <b>using namespace Another problem arises if you put a <b>using namespace
std;</b> declaration at the top, and include <tt>&lt;ctype.h&gt;</tt>. This will result in std;</b> declaration at the top, and include <tt>&lt;ctype.h&gt;</tt>. This will result in
ambiguities between the definitions in the global namespace ambiguities between the definitions in the global namespace
...@@ -506,58 +552,91 @@ ...@@ -506,58 +552,91 @@
definitions in namespace <b>std::</b> definitions in namespace <b>std::</b>
(<b>&lt;cctype&gt;</b>). (<b>&lt;cctype&gt;</b>).
</p> </p>
<p> <p>
The solution to this problem was posted to the libstdc++-v3 The solution to this problem was posted to the libstdc++-v3
mailing-list: mailing-list:
Benjamin Kosnik <tt>&lt;<a href="mailto:bkoz@redhat.com">bkoz@redhat.com</a>&gt;</tt> writes: Benjamin Kosnik <tt>&lt;<a href="mailto:bkoz@redhat.com">bkoz@redhat.com</a>&gt;</tt> writes:
" `
--enable-cshadow-headers is currently broken. As a result, shadow --enable-cshadow-headers is currently broken. As a result, shadow
headers are not being searched.... headers are not being searched....
" '
</p> </p>
</div> </div>
<div class="section" id="sec-stream-state"> <div class="section">
<h2 class="title" style="clear: all"> <a name="sec-stream-state"></a>
<a name="sec-stream-state"><b>7. <div class="titlepage"><div><h2 class="title" style="clear: all">
<a name="sec-stream-state"></a>
<span class="label">7.</span> <span class="title">
State of streams State of streams
</b></a> </span>
</h2> </h2></div></div>
<p> <p>
At least some older implementations don't have At least some older implementations don't have
<b>std::ios_base</b>, so you should use <b>std::ios_base</b>, so you should use
<b>std::ios::badbit</b>, <b>std::ios::failbit</b> <b>std::ios::badbit</b>, <b>std::ios::failbit</b>
and <b>std::ios::eofbit</b> and and <b>std::ios::eofbit</b> and
<b>std::ios::goodbit</b>. <b>std::ios::goodbit</b>.
</p> </p>
</div> </div>
<div class="section" id="sec-vector-at"> <div class="section">
<h2 class="title" style="clear: all"> <a name="sec-vector-at"></a>
<a name="sec-vector-at"><b>8. vector::at is missing (i.e. gcc 2.95.2)</b></a> <div class="titlepage"><div><h2 class="title" style="clear: all">
</h2> <a name="sec-vector-at"></a>
<p> <span class="label">8.</span> <span class="title">vector::at is missing (i.e. gcc 2.95.x)</span>
For my use, I added it to </h2></div></div>
<p>
You could easily modify the header-files:
<tt>prefix/include/g++-3/stl_vector.h</tt>: <tt>prefix/include/g++-3/stl_vector.h</tt>:
<pre class="programlisting"> <pre class="programlisting">
reference operator[](size_type __n) { return *(begin() + __n); } reference operator[](size_type __n) { return *(begin() + __n); }
reference at(size_type __n) { reference at(size_type __n) {
if (begin() + __n &gt;= end()) if (begin() + __n &gt;= end())
throw out_of_range("vector::at"); throw out_of_range(&quot;vector::at&quot;);
return *(begin() + __n); return *(begin() + __n);
} }
const_reference operator[](size_type __n) const { return *(begin() + __n); } const_reference operator[](size_type __n) const { return *(begin() + __n); }
const_reference at(size_type __n) const { const_reference at(size_type __n) const {
if (begin() + __n &gt;= end()) if (begin() + __n &gt;= end())
throw out_of_range("vector::at"); throw out_of_range(&quot;vector::at&quot;);
return *(begin() + __n); return *(begin() + __n);
} }
</pre> </pre>
</p> (and so on for <b>deque</b> and <b>string</b>)
</div>
<div class="section" id="sec-eof"> Of course a better solution is to add an autoconf-test for this:
<h2 class="title" style="clear: all"> <pre class="programlisting">
<a name="sec-eof"><b>9. Using std::char_traits&lt;char&gt;::eof()</b></a> AC_MSG_CHECKING(for container::at)
</h2> AC_TRY_COMPILE(
<p> [
#include &lt;vector&gt;
#include &lt;deque&gt;
#include &lt;string&gt;
using namespace std;
],
[
deque&lt;int&gt; test_deque(3);
test_deque.at(2);
vector&lt;int&gt; test_vector(2);
test_vector.at(1);
string test_string(&quot;test_string&quot;);
test_string.at(3);
],
[AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_CONTAINER_AT)],
[AC_MSG_RESULT(no)])
</pre>
If you are using other (non-GNU) compilers it might be a good idea
to check for <b>string::at</b> separately.
</p>
</div>
<div class="section">
<a name="sec-eof"></a>
<div class="titlepage"><div><h2 class="title" style="clear: all">
<a name="sec-eof"></a>
<span class="label">9.</span> <span class="title">Using std::char_traits&lt;char&gt;::eof()</span>
</h2></div></div>
<p>
<pre class="programlisting"> <pre class="programlisting">
#ifdef HAVE_CHAR_TRAITS #ifdef HAVE_CHAR_TRAITS
#define CPP_EOF std::char_traits&lt;char&gt;::eof() #define CPP_EOF std::char_traits&lt;char&gt;::eof()
...@@ -566,12 +645,14 @@ ...@@ -566,12 +645,14 @@
#endif #endif
</pre> </pre>
</p> </p>
</div> </div>
<div class="section" id="sec-string-clear"> <div class="section">
<h2 class="title" style="clear: all"> <a name="sec-string-clear"></a>
<a name="sec-string-clear"><b>10. Using string::clear()/string::erase()</b></a> <div class="titlepage"><div><h2 class="title" style="clear: all">
</h2> <a name="sec-string-clear"></a>
<p> <span class="label">10.</span> <span class="title">Using string::clear()/string::erase()</span>
</h2></div></div>
<p>
There are two functions for deleting the contents of a string: There are two functions for deleting the contents of a string:
<b>clear</b> and <b>erase</b> (the latter <b>clear</b> and <b>erase</b> (the latter
returns the string). returns the string).
...@@ -589,18 +670,21 @@ ...@@ -589,18 +670,21 @@
</pre> </pre>
The implementation of <b>erase</b> seems to be more The implementation of <b>erase</b> seems to be more
complicated (from libstdc++-v3), but <b>clear</b> is not complicated (from libstdc++-v3), but <b>clear</b> is not
implemented in gcc 2.95.2's libstdc++, so you should use implemented in gcc 2.95.x's libstdc++, so you should use
<b>erase</b> (which is probably faster than <b>erase</b> (which is probably faster than
<b>operator=(charT*)</b>). <b>operator=(charT*)</b>).
</p> </p>
</div> </div>
<div class="section" id="sec-stringstream"> <div class="section">
<h2 class="title" style="clear: all"> <a name="sec-stringstream"></a>
<a name="sec-stringstream"><b>11. Using stringstream's</b></a> <div class="titlepage"><div><h2 class="title" style="clear: all">
</h2> <a name="sec-stringstream"></a>
<p> <span class="label">11.</span> <span class="title">Using stringstream's</span>
Libstdc++-v3 includes the new </h2></div></div>
<b>i/ostringstream</b>-classes, (<tt>&lt;sstream&gt;</tt>), but with older <p>
Libstdc++-v3 provides the new
<b>i/ostringstream</b>-classes,
(<tt>&lt;sstream&gt;</tt>), but with older
implementations you still have to use <b>i/ostrstream</b> implementations you still have to use <b>i/ostrstream</b>
(<tt>&lt;strstream&gt;</tt>): (<tt>&lt;strstream&gt;</tt>):
<pre class="programlisting"> <pre class="programlisting">
...@@ -610,37 +694,27 @@ ...@@ -610,37 +694,27 @@
#include &lt;strstream&gt; #include &lt;strstream&gt;
#endif #endif
</pre> </pre>
<div class="itemizedlist"> <div class="itemizedlist"><ul>
<ul> <li><p>
<li> <a name="id2665237"></a> <b>strstream</b> is considered to be
<a name="N3595"></a>
<p> <b>strstream</b> is considered to be
deprecated deprecated
</p> </p></li>
</li> <li><p>
<li> <a name="id2665256"></a> <b>strstream</b> is limited to
<a name="N3603"></a>
<p> <b>strstream</b> is limited to
<b>char</b> <b>char</b>
</p> </p></li>
</li> <li><p>
<li> <a name="id2665271"></a> with <b>ostringstream</b> you don't
<a name="N3614"></a>
<p> with <b>ostringstream</b> you don't
have to take care of terminating the string or freeing its have to take care of terminating the string or freeing its
memory memory
</p> </p></li>
</li> <li><p>
<li> <a name="id2665284"></a> <b>istringstream</b> can be re-filled
<a name="N3622"></a>
<p> <b>istringstream</b> can be re-filled
(clear(); str(input);) (clear(); str(input);)
</p></li>
</ul></div>
</p> </p>
</li> <p>
</ul>
</div>
</p>
<p>
You can then use output-stringstreams like this: You can then use output-stringstreams like this:
<pre class="programlisting"> <pre class="programlisting">
#ifdef HAVE_SSTREAM #ifdef HAVE_SSTREAM
...@@ -648,7 +722,7 @@ ...@@ -648,7 +722,7 @@
#else #else
std::ostrstream oss; std::ostrstream oss;
#endif #endif
oss &lt;&lt; "Name=" &lt;&lt; m_name &lt;&lt; ", number=" &lt;&lt; m_number &lt;&lt; std::endl; oss &lt;&lt; &quot;Name=&quot; &lt;&lt; m_name &lt;&lt; &quot;, number=&quot; &lt;&lt; m_number &lt;&lt; std::endl;
... ...
#ifndef HAVE_SSTREAM #ifndef HAVE_SSTREAM
oss &lt;&lt; std::ends; // terminate the char*-string oss &lt;&lt; std::ends; // terminate the char*-string
...@@ -663,7 +737,7 @@ ...@@ -663,7 +737,7 @@
#endif #endif
</pre> </pre>
</p> </p>
<p> <p>
Input-stringstreams can be used similarly: Input-stringstreams can be used similarly:
<pre class="programlisting"> <pre class="programlisting">
std::string input; std::string input;
...@@ -704,23 +778,24 @@ ...@@ -704,23 +778,24 @@
} }
</pre> </pre>
</p> </p>
<p> <p>
I have read the Josuttis book on Standard C++, so some information I have read the Josuttis book on Standard C++, so some information
comes from there. Additionally, there is information in comes from there. Additionally, there is information in
"info iostream", which covers the old implementation that gcc 2.95.2 &quot;info iostream&quot;, which covers the old implementation that gcc 2.95.x
uses. uses.
</p> </p>
</div> </div>
<div class="section" id="sec-about"> <div class="section">
<h2 class="title" style="clear: all"> <a name="sec-about"></a>
<a name="sec-about"><b>12. About...</b></a> <div class="titlepage"><div><h2 class="title" style="clear: all">
</h2> <a name="sec-about"></a>
<p> <span class="label">12.</span> <span class="title">About...</span>
</h2></div></div>
<p>
Please send any experience, additions, corrections or questions to Please send any experience, additions, corrections or questions to
<a href="mailto:fnatter@gmx.net">fnatter@gmx.net</a> or for <a href="mailto:fnatter@gmx.net" target="_top">fnatter@gmx.net</a> or for
discussion to the libstdc++-v3-mailing-list. discussion to the libstdc++-v3-mailing-list.
</p> </p>
</div> </div>
</div> </div></body>
</body>
</html> </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