Skip to content

R
riscv-gcc-1
Commit 17e7554f by Felix Natter Committed by Phil Edwards
Options

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
Showing with 801 additions and 722 deletions
libstdc++-v3/ChangeLog
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
......
libstdc++-v3/docs/html/17_intro/porting-howto.html
<!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>
This document can be distributed under the FDL <p>
(<a href="http://www.gnu.org">www.gnu.org</a>) This document can be distributed under the FDL
</p> (<a href="http://www.gnu.org" target="_top">www.gnu.org</a>)
<p class="pubdate">what kind of a date ? I don't drink !</p> </p>
<div class="revhistory"> </div></div>
<table width="100%" border="1"> <div><p class="pubdate">Tue Jun 5 20:07:49 2001</p></div>
<tr> <div><div class="revhistory"><table border="1" width="100%" summary="Revision history">
<th colspan="3" valign="top" align="left"><b>Revision History</b></th> <tr><th align="left" valign="top" colspan="3"><b>Revision History</b></th></tr>
</tr> <tr>
<tr> <td align="left">Revision 0.5</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">Thu Jun 1 13:06:50 2000</td>
</tr> <td align="left">fnatter</td>
<tr> </tr>
<td colspan="3" align="left">First docbook-version.</td> <tr><td align="left" colspan="3">First docbook-version.</td></tr>
</tr> <tr>
<tr> <td align="left">Revision 0.8</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">Sun Jul 30 20:28:40 2000</td>
</tr> <td align="left">fnatter</td>
<tr> </tr>
<td colspan="3" align="left">First released version using docbook-xml <tr><td align="left" colspan="3">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>
Some notes on porting applications from libstdc++-2.90 (or earlier <td align="left">Revision 0.9.2</td>
versions) to libstdc++-v3. Not speaking in terms of the GNU libstdc++ <td align="left">Tue Jun 5 20:07:49 2001</td>
implementations, this means porting from earlier versions of the <td align="left">fnatter</td>
C++-Standard to ISO 14882. </tr>
</p> <tr><td align="left" colspan="3">
</div> a fix, added hint on increased portability of C-shadow-headers,
<hr> added autoconf-test HAVE_CONTAINER_AT
</div> </td></tr>
<div class="toc"> </table></div></div>
<p> <div><div class="abstract">
<b>Table of Contents</b> <p>
</p> <a name="id2715202"></a>
<dl> <b>Abstract</b>
<dt>1. <a href="#sec-nsstd">Namespace std::</a> </p>
</dt> <p>
<dd> Some notes on porting applications from libstdc++-2.90 (or earlier
<dl> versions) to libstdc++-v3. Not speaking in terms of the GNU libstdc++
<dt>1.1.1. <a href="#sec-gtkmm-hack">Using <i>namespace implementations, this means porting from earlier versions of the
composition</i> if the project uses a separate C++-Standard to ISO 14882.
namespace</a> </p>
</dt> </div></div>
<dt>1.1.2. <a href="#sec-emptyns">Defining an empty namespace std</a> <hr>
</dt> </div>
<dt>1.1.3. <a href="#sec-avoidfqn">Avoid to use fully qualified names <div class="toc">
(i.e. std::string)</a> <p><b>Table of Contents</b></p>
</dt> <dl>
<dt>1.1.4. <a href="#sec-osprojects">How some open-source-projects deal <dt>1. <a href="#sec-nsstd">Namespace std::</a>
with this</a> </dt>
</dt> <dd><dl>
</dl> <dt>1.1.1. <a href="#sec-gtkmm-hack">Using <i>namespace
</dd> composition</i> if the project uses a separate
<dt>2. <a href="#sec-nocreate">there is no ios::nocreate/ios::noreplace namespace</a>
in ISO 14882</a> </dt>
</dt> <dt>1.1.2. <a href="#sec-emptyns">Defining an empty namespace std</a>
<dt>3. <a href="#sec-stream::attach"><b>stream::attach(int </dt>
fd)</b> is not in the standard any more</a> <dt>1.1.3. <a href="#sec-avoidfqn">Avoid to use fully qualified names
</dt> (i.e. std::string)</a>
<dt>4. <a href="#sec-headers">The new headers</a> </dt>
</dt> <dt>1.1.4. <a href="#sec-osprojects">How some open-source-projects deal
<dd> with this</a>
<dl> </dt>
<dt>4.4.1. <a href="#sec-cheaders">New headers replacing C-headers</a> </dl></dd>
</dt> <dt>2. <a href="#sec-nocreate">there is no ios::nocreate/ios::noreplace
<dt>4.4.2. <a href="#sec-fstream-header"> in ISO 14882</a>
<tt>&lt;fstream&gt;</tt> does </dt>
not define <b>std::cout</b>, <dt>3. <a href="#sec-stream::attach">
<b>std::cin</b> etc.</a> <b>stream::attach(int
</dt> fd)</b> is not in the standard any more</a>
</dl> </dt>
</dd> <dt>4. <a href="#sec-headers">The new headers</a>
<dt>5. <a href="#sec-iterators">Iterators</a> </dt>
</dt> <dd><dl>
<dt>6. <a href="#sec-macros"> <dt>4.4.1. <a href="#sec-cheaders">New headers replacing C-headers</a>
Libc-macros (i.e. <b>isspace</b> from </dt>
<tt>&lt;cctype&gt;</tt>)</a> <dt>4.4.2. <a href="#sec-fstream-header">
</dt> <tt>&lt;fstream&gt;</tt> does
<dt>7. <a href="#sec-stream-state"> not define <b>std::cout</b>,
State of streams <b>std::cin</b> etc.</a>
</a> </dt>
</dt> </dl></dd>
<dt>8. <a href="#sec-vector-at">vector::at is missing (i.e. gcc 2.95.2)</a> <dt>5. <a href="#sec-iterators">Iterators</a>
</dt> </dt>
<dt>9. <a href="#sec-eof">Using std::char_traits&lt;char&gt;::eof()</a> <dt>6. <a href="#sec-macros">
</dt> Libc-macros (i.e. <b>isspace</b> from
<dt>10. <a href="#sec-string-clear">Using string::clear()/string::erase()</a> <tt>&lt;cctype&gt;</tt>)</a>
</dt> </dt>
<dt>11. <a href="#sec-stringstream">Using stringstream's</a> <dt>7. <a href="#sec-stream-state">
</dt> State of streams
<dt>12. <a href="#sec-about">About...</a> </a>
</dt> </dt>
</dl> <dt>8. <a href="#sec-vector-at">vector::at is missing (i.e. gcc 2.95.x)</a>
</div> </dt>
<p> <dt>9. <a href="#sec-eof">Using std::char_traits&lt;char&gt;::eof()</a>
In the following, when I say portable, I will refer to "portable among ISO </dt>
14882-implementations". On the other hand, if I say "backportable" or <dt>10. <a href="#sec-string-clear">Using string::clear()/string::erase()</a>
"conservative", I am talking about "compiles with older </dt>
libstdc++-implementations". <dt>11. <a href="#sec-stringstream">Using stringstream's</a>
</dt>
<dt>12. <a href="#sec-about">About...</a>
</dt>
</dl>
</div>
<p>
In the following, when I say portable, I will refer to &quot;portable among ISO
14882-implementations&quot;. On the other hand, if I say &quot;backportable&quot; or
&quot;conservative&quot;, I am talking about &quot;compiles with older
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>
The latest C++-standard (ISO-14882) requires that the standard </h2></div></div>
C++-library is defined in namespace std::. Thus, in order to use <p>
classes from the standard C++-library, you can do one of three The latest C++-standard (ISO-14882) requires that the standard
things: C++-library is defined in namespace std::. Thus, in order to use
<div class="itemizedlist"> classes from the standard C++-library, you can do one of three
<ul> things:
<li> <div class="itemizedlist"><ul>
<a name="N2712"></a> <li><p>
<p>wrap your code in <b>namespace std { <a name="id2715113"></a>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> <i>using-declaration</i> in your source (either
<p>put a kind of <b>using namespace std;</b> or i.e. <b>using
<i>using-declaration</i> in your source (either std::string;</b>) =&gt; works well for source-files, but
<b>using namespace std;</b> or i.e. <b>using cannot be used in header-files.
std::string;</b>) =&gt; works well for source-files, but </p></li>
cannot be used in header-files. <li><p>
</p> <a name="id2668731"></a>use a <i>fully qualified name</i> for
</li> each libstdc++-symbol (i.e. <b>std::string</b>,
<li> <b>std::cout</b>) =&gt; can always be used
<a name="N2736"></a> </p></li>
<p>use a <i>fully qualified name</i> for </ul></div>
each libstdc++-symbol (i.e. <b>std::string</b>, </p>
<b>std::cout</b>) =&gt; can always be used <p>
</p> Because there are many compilers which still use an implementation
</li> that does not have the standard C++-library in namespace
</ul> <b>std::</b>, some care is required to support these as
</div> well.
</p> </p>
<p> <p>
Because there are many compilers which still use an implementation Namespace back-portability-issues are generally not a problem with
that does not have the standard C++-library in namespace g++, because versions of g++ that do not have libstdc++ in
<b>std::</b>, some care is required to support these as <b>std::</b> use <b>-fno-honor-std</b>
well. (ignore <b>std::</b>, <b>:: = std::</b>) by
</p> default. That is, the responsibility for enabling or disabling
<p> <b>std::</b> is on the user; the maintainer does not have
Namespace back-portability-issues are generally not a problem with to care about it. This probably applies to some other compilers as
g++, because versions of g++ that do not have libstdc++ in well.
<b>std::</b> use <b>-fno-honor-std</b> </p>
(ignore <b>std::</b>, <b>:: = std::</b>) by <p>
default. That is, the responsibility for enabling or disabling The following sections list some possible solutions to support compilers
<b>std::</b> is on the user; the maintainer does not have that cannot ignore std::.
to care about it. This probably applies to some other compilers as </p>
well. <div class="section">
</p> <a name="sec-gtkmm-hack"></a>
<p> <div class="titlepage"><div><h3 class="title">
The following sections list some possible solutions to support compilers <a name="sec-gtkmm-hack"></a>
that cannot ignore std::. <span class="label">1.1.1.</span> <span class="title">Using <i>namespace
</p> composition</i> if the project uses a separate
<div class="section" id="sec-gtkmm-hack"> namespace</span>
<h3 class="title"> </h3></div></div>
<a name="sec-gtkmm-hack"><b>1.1.1. Using <i>namespace <p>
composition</i> if the project uses a separate <a href="http://gtkmm.sourceforge.net" target="_top">Gtk--</a> defines
namespace</b></a> most of its classes in namespace Gtk::. Thus, it was possible to
</h3> adapt Gtk-- to namespace std:: by using a C++-feature called
<p> <i>namespace composition</i>. This is what happens if
<a href="http://gtkmm.sourceforge.net">Gtk--</a> defines you put a <i>using</i>-declaration into a
most of its classes in namespace Gtk::. Thus, it was possible to namespace-definition: the imported symbol(s) gets imported into the
adapt Gtk-- to namespace std:: by using a C++-feature called currently active namespace(s). For example:
<i>namespace composition</i>. This is what happens if <pre class="programlisting">
you put a <i>using</i>-declaration into a namespace Gtk {
namespace-definition: the imported symbol(s) gets imported into the using std::string;
currently active namespace(s). For example: class Window { ... }
<pre class="programlisting"> }
namespace Gtk { </pre>
using std::string; In this example, <b>std::string</b> gets imported into
class Window { ... } namespace Gtk::. The result is that you don't have to use
} <b>std::string</b> in this header, but still
</pre> <b>std::string</b> does not get imported into
In this example, <b>std::string</b> gets imported into user-space (the global namespace ::) unless the user does
namespace Gtk::. The result is that you don't have to use <b>using namespace Gtk;</b> (which is not recommended
<b>std::string</b> in this header, but still practice for Gtk--, so it is not a problem). Additionally, the
<b>std::string</b> does not get imported into <b>using</b>-declarations are wrapped in macros that
user-space (the global namespace ::) unless the user does are set based on autoconf-tests to either &quot;&quot; or i.e. <b>using
<b>using namespace Gtk;</b> (which is not recommended std::string;</b> (depending on whether the system has
practice for Gtk--, so it is not a problem). Additionally, the libstdc++ in <b>std::</b> or not). (ideas from
<b>using</b>-declarations are wrapped in macros that <tt>&lt;<a href="mailto:llewelly@dbritsch.dsl.xmission.com">llewelly@dbritsch.dsl.xmission.com</a>&gt;</tt>, Karl Nelson
are set based on autoconf-tests to either "" or i.e. <b>using <tt>&lt;<a href="mailto:kenelson@ece.ucdavis.edu">kenelson@ece.ucdavis.edu</a>&gt;</tt>)
std::string;</b> (depending on whether the system has </p>
libstdc++ in <b>std::</b> or not). (ideas from </div>
<tt>&lt;<a href="mailto:llewelly@dbritsch.dsl.xmission.com">llewelly@dbritsch.dsl.xmission.com</a>&gt;</tt>, Karl Nelson <div class="section">
<tt>&lt;<a href="mailto:kenelson@ece.ucdavis.edu">kenelson@ece.ucdavis.edu</a>&gt;</tt>) <a name="sec-emptyns"></a>
</p> <div class="titlepage"><div><h3 class="title">
</div> <a name="sec-emptyns"></a>
<div class="section" id="sec-emptyns"> <span class="label">1.1.2.</span> <span class="title">Defining an empty namespace std</span>
<h3 class="title"> </h3></div></div>
<a name="sec-emptyns"><b>1.1.2. Defining an empty namespace std</b></a> <p>
</h3> By defining an (empty) namespace <b>std::</b> before
<p> using it, you avoid getting errors on systems where no part of the
By defining an (empty) namespace <b>std::</b> before library is in namespace std:
using it, you avoid getting errors on systems where no part of the <pre class="programlisting">
library is in namespace std: namespace std { }
<pre class="programlisting"> using namespace std;
namespace std { } </pre>
using namespace std; </p>
</pre> </div>
</p> <div class="section">
</div> <a name="sec-avoidfqn"></a>
<div class="section" id="sec-avoidfqn"> <div class="titlepage"><div><h3 class="title">
<h3 class="title"> <a name="sec-avoidfqn"></a>
<a name="sec-avoidfqn"><b>1.1.3. Avoid to use fully qualified names <span class="label">1.1.3.</span> <span class="title">Avoid to use fully qualified names
(i.e. std::string)</b></a> (i.e. std::string)</span>
</h3> </h3></div></div>
<p> <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>
This information was gathered around May 2000. It may not be correct </h3></div></div>
by the time you read this. <p>
</p> This information was gathered around May 2000. It may not be correct
<div class="table"> by the time you read this.
<p> </p>
<a name="N2901"></a><b>Table 1. Namespace std:: in Open-Source programs</b> <div class="table">
</p> <p>
<table border="1"> <a name="id2668681"></a>
<colgroup> <b>Table 1. Namespace std:: in Open-Source programs</b>
<col> </p>
<col> <table summary="Namespace std:: in Open-Source programs" border="1">
</colgroup> <colgroup>
<tbody> <col>
<tr> <col>
<td><a href="http://www.clanlib.org">clanlib</a></td><td>usual</td> </colgroup>
</tr> <tbody>
<tr> <tr>
<td><a href="http://pingus.seul.org">pingus</a></td><td>usual</td> <td><a href="http://www.clanlib.org" target="_top">clanlib</a></td>
</tr> <td>usual</td>
<tr> </tr>
<td><a href="http://www.mozilla.org">mozilla</a></td><td>usual</td> <tr>
</tr> <td><a href="http://pingus.seul.org" target="_top">pingus</a></td>
<tr> <td>usual</td>
<td><a href="http://www.mnemonic.org">mnemonic</a></td><td>none</td> </tr>
</tr> <tr>
<tr> <td><a href="http://www.mozilla.org" target="_top">mozilla</a></td>
<td><a href="http://libsigc.sourceforge.net"> <td>usual</td>
libsigc++</a></td><td>conservative-impl</td> </tr>
</tr> <tr>
</tbody> <td><a href="http://www.mnemonic.org" target="_top">mnemonic</a></td>
</table> <td>none</td>
</div> </tr>
<div class="table"> <tr>
<p> <td><a href="http://libsigc.sourceforge.net" target="_top">
<a name="N2978"></a><b>Table 2. Notations for categories</b> libsigc++</a></td>
</p> <td>conservative-impl</td>
<table border="1"> </tr>
<colgroup> </tbody>
<col> </table>
<col> </div>
</colgroup> <div class="table">
<tbody> <p>
<tr> <a name="id2666288"></a>
<td>usual</td><td>mostly fully qualified names and some <b>Table 2. Notations for categories</b>
using-declarations (but not in headers)</td> </p>
</tr> <table summary="Notations for categories" border="1">
<tr> <colgroup>
<td>none</td><td>no namespace std at all</td> <col>
</tr> <col>
<tr> </colgroup>
<td>conservative-impl</td><td>wrap all <tbody>
namespace-handling in macros to support compilers without <tr>
namespace-support (no libstdc++ used in headers)</td> <td>usual</td>
</tr> <td>mostly fully qualified names and some
</tbody> using-declarations (but not in headers)</td>
</table> </tr>
</div> <tr>
<p> <td>none</td>
As you can see, this currently lacks an example of a project which <td>no namespace std at all</td>
uses libstdc++-symbols in headers in a back-portable way (except </tr>
for Gtk--: see the <a href="#"></a>). <tr>
</p> <td>conservative-impl</td>
</div> <td>wrap all
</div> namespace-handling in macros to support compilers without
<div class="section" id="sec-nocreate"> namespace-support (no libstdc++ used in headers)</td>
<h2 class="title" style="clear: all"> </tr>
<a name="sec-nocreate"><b>2. there is no ios::nocreate/ios::noreplace </tbody>
in ISO 14882</b></a> </table>
</h2> </div>
<p> <p>
I have seen <b>ios::nocreate</b> being used for input-streams, As you can see, this currently lacks an example of a project which
most probably because the authors thought it would be more correct uses libstdc++-symbols in headers in a back-portable way (except
to specify nocreate "explicitly". So you can simply leave it out for Gtk--: see the <a href="#sec-gtkmm-hack"></a>).
for input-streams. </p>
</p> </div>
<p> </div>
For output streams, "nocreate" is probably the default, unless you <div class="section">
specify <b>std::ios::trunc</b> ? To be safe, you can open <a name="sec-nocreate"></a>
the file for reading, check if it has been opened, and then decide <div class="titlepage"><div><h2 class="title" style="clear: all">
whether you want to create/replace or not. To my knowledge, even <a name="sec-nocreate"></a>
older implementations support <b>app</b>, <span class="label">2.</span> <span class="title">there is no ios::nocreate/ios::noreplace
<b>ate</b> and <b>trunc</b> (except for in ISO 14882</span>
<b>app</b> ?). </h2></div></div>
</p> <p>
</div> I have seen <b>ios::nocreate</b> being used for
<div class="section" id="sec-stream::attach"> input-streams, most probably because the author thought it would be
<h2 class="title" style="clear: all"> more correct to specify nocreate &quot;explicitly&quot;. So you can simply
<a name="sec-stream::attach"><b>3. <b>stream::attach(int leave it out for input-streams.
fd)</b> is not in the standard any more</b></a> </p>
</h2> <p>
<p> For output streams, &quot;nocreate&quot; is probably the default, unless you
When using libstdc++-v3, you can use specify <b>std::ios::trunc</b> ? To be safe, you can open
<div id="N3082" class="funcsynopsis"> the file for reading, check if it has been opened, and then decide
<p> whether you want to create/replace or not. To my knowledge, even
</p> older implementations support <b>app</b>,
<a name="N3082"></a> <b>ate</b> and <b>trunc</b> (except for
<pre class="funcsynopsisinfo"> <b>app</b> ?).
#include &lt;fstream&gt; </p>
</pre> </div>
<p> <div class="section">
<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> <a name="sec-stream::attach"></a>
</p> <div class="titlepage"><div><h2 class="title" style="clear: all">
<p> <a name="sec-stream::attach"></a>
</p> <span class="label">3.</span> <span class="title">
</div> <b>stream::attach(int
For a portable solution (if there is one), you need to implement a fd)</b> is not in the standard any more</span>
subclass of <b>streambuf</b> which opens a file given a </h2></div></div>
descriptor, and then pass an instance of this to the <p>
stream-constructor (from the Josuttis-book). Phil Edwards <tt>&lt;<a href="mailto:pedwards@disaster.jaj.com">pedwards@disaster.jaj.com</a>&gt;</tt> writes:
</p> It was considered and rejected. Not all environments use file
</div> descriptors. Of those that do, not all of them use integers to represent
<div class="section" id="sec-headers"> them.
<h2 class="title" style="clear: all"> </p>
<a name="sec-headers"><b>4. The new headers</b></a> <p>
</h2> When using libstdc++-v3, you can use
<p> <div class="funcsynopsis" id="id2666593">
All new headers can be seen in this <a href="../../testsuite/17_intro/headers.cc">source-code</a>. <p>
</p> <a name="id2666593"></a>
<p> <pre class="funcsynopsisinfo">
I think it is a problem for libstdc++-v3 to add links or wrappers #include &lt;fstream&gt;
for the old headers, because the implementation has changed, and </pre>
the header name-changes indicate this. It might be preferable to <p><code>
use the new headers and tell users of old compilers that they <code class="funcdef">int <b class="fsfunc">basic_filebuf</b>
should create links (which is what they will have to do sometime </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>
anyway). <p>
</p> </div>
<div class="section" id="sec-cheaders"> but the the signature of this constructor has changed often, and
<h3 class="title"> it might change again.
<a name="sec-cheaders"><b>4.4.1. New headers replacing C-headers</b></a> For a portable solution (among systems which use
</h3> filedescriptors), you need to implement a subclass of
<p> <b>streambuf</b> (or
You should not use the C-headers (except for system-level headers) <b>basic_streambuf&lt;..&gt;</b>) which opens a file
from C++ programs. Instead, you should use a set of headers that given a descriptor, and then pass an instance of this to the
are named by prepending 'c' and, as usual, ommiting the extension stream-constructor (from the Josuttis-book).
(.h). For example, instead of using <tt>&lt;math.h&gt;</tt>, you should use <tt>&lt;cmath&gt;</tt>. The standard </p>
specifies that if you include the C-style header (<tt>&lt;math.h&gt;</tt> in this case), the symbols </div>
will be available both in the global namespace and in namespace <div class="section">
<b>std::</b> (libstdc++-v3, version 2.90.8 currently <a name="sec-headers"></a>
puts them in <b>std::</b> only) On the other hand, if <div class="titlepage"><div><h2 class="title" style="clear: all">
you include only the new header (i.e. <tt>&lt;pcmath&gt;</tt>), the symbols will only be <a name="sec-headers"></a>
defined in namespace <b>std::</b> (and macros will be <span class="label">4.</span> <span class="title">The new headers</span>
converted to inline-functions). </h2></div></div>
</p> <p>
<p> All new headers can be seen in this <a href="headers_cc.txt" target="_top">
For more information on this, and for information on how the GNU source-code</a>.
C++ implementation reuses ("shadows") the C library-functions, have </p>
a look at <a href="http://www.cantrip.org/cheaders.html"> <p>
www.cantrip.org</a>. The old C++-headers (iostream.h etc.) are available, but gcc generates
</p> a warning that you are using deprecated headers.
</div> </p>
<div class="section" id="sec-fstream-header"> <div class="section">
<h3 class="title"> <a name="sec-cheaders"></a>
<a name="sec-fstream-header"><b>4.4.2. <div class="titlepage"><div><h3 class="title">
<tt>&lt;fstream&gt;</tt> does <a name="sec-cheaders"></a>
not define <b>std::cout</b>, <span class="label">4.4.1.</span> <span class="title">New headers replacing C-headers</span>
<b>std::cin</b> etc.</b></a> </h3></div></div>
</h3> <p>
<p> You should not use the C-headers (except for system-level
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 headers) from C++ programs. Instead, you should use a set of
<b>cout</b>, <b>cin</b> and so on. Because headers that are named by prepending 'c' and, as usual,
of the templatized iostreams in libstdc++-v3, you need to include omitting the extension (.h). For example, instead of using
<tt>&lt;iostream&gt;</tt> <tt>&lt;math.h&gt;</tt>, you
explicitly to define these. should use <tt>&lt;cmath&gt;</tt>. In some cases this has
</p> the advantage that the C++-header is more standardized than
</div> the C-header (i.e. <tt>&lt;ctime&gt;</tt> (almost)
</div> corresponds to either <tt>&lt;time.h&gt;</tt> or <tt>&lt;sys/time.h&gt;</tt>).
<div class="section" id="sec-iterators">
<h2 class="title" style="clear: all">
<a name="sec-iterators"><b>5. Iterators</b></a>
</h2>
<p>
The following are not proper uses of iterators, but may be working
fixes for existing uses of iterators.
<div class="itemizedlist">
<ul>
<li>
<a name="N3282"></a>
<p>you cannot do
<b>ostream::operator&lt;&lt;(iterator)</b> to
print the address of the iterator =&gt; use
<b>operator&lt;&lt; &amp;*iterator</b> instead ?
</p>
</li>
<li>
<a name="N3303"></a>
<p>you cannot clear an iterator's reference
(<b>iterator = 0</b>) =&gt; use
<b>iterator = iterator_type();</b> ?
</p>
</li>
<li>
<a name="N3316"></a>
<p>
<b>if (iterator)</b> won't work any
more =&gt; use <b>if (iterator != iterator_type())</b>
?</p>
</li>
</ul>
</div>
</p>
</div>
<div class="section" id="sec-macros">
<h2 class="title" style="clear: all">
<a name="sec-macros"><b>6.
Libc-macros (i.e. <b>isspace</b> from
<tt>&lt;cctype&gt;</tt>)</b></a>
</h2>
<p>
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
as described in the <a href="#"></a>.
</p>
<p>
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
is not back-portable to use fully qualified names. For example:
<pre class="programlisting">
#include &lt;cctype&gt;
int main() { std::isspace('X'); }
</pre>
will result in something like this (unless using g++-v3):
<pre class="programlisting">
std:: (__ctype_b[(int) ( ( 'X' ) )] &amp; (unsigned short int)
_ISspace ) ;
</pre>
</p>
<p>
One solution I can think of is to test for -v3 using
autoconf-macros, and define macros for each of the C-functions
(maybe that is possible with one "wrapper" macro as well ?).
</p>
<p>
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
macro which tells <tt>&lt;ctype.h&gt;</tt> to define functions
instead of macros:
<pre class="programlisting">
// This keeps isalnum, et al from being propagated as macros.
#if __linux__
#define __NO_CTYPE 1
#endif
[ now include &lt;ctype.h&gt; ] The standard specifies that if you include the C-style header
</pre> (<tt>&lt;math.h&gt;</tt> in
</p> this case), the symbols will be available both in the global
<p> namespace and in namespace <b>std::</b> (but
Another problem arises if you put a <b>using namespace libstdc++ does not yet have fully compliant headers) On the
std;</b> declaration at the top, and include <tt>&lt;ctype.h&gt;</tt>. This will result in other hand, if you include only the new header (i.e. <tt>&lt;cmath&gt;</tt>), the symbols
ambiguities between the definitions in the global namespace will only be defined in namespace <b>std::</b>
(<tt>&lt;ctype.h&gt;</tt>) and the (and macros will be converted to inline-functions).
definitions in namespace <b>std::</b> </p>
(<b>&lt;cctype&gt;</b>). <p>
</p> For more information on this, and for information on how the
<p> GNU C++ implementation might reuse (&quot;shadow&quot;) the C
The solution to this problem was posted to the libstdc++-v3 library-functions, have a look at <a href="http://www.cantrip.org/cheaders.html" target="_top">
mailing-list: www.cantrip.org</a>.
Benjamin Kosnik <tt>&lt;<a href="mailto:bkoz@redhat.com">bkoz@redhat.com</a>&gt;</tt> writes: </p>
" </div>
--enable-cshadow-headers is currently broken. As a result, shadow <div class="section">
headers are not being searched.... <a name="sec-fstream-header"></a>
" <div class="titlepage"><div><h3 class="title">
</p> <a name="sec-fstream-header"></a>
</div> <span class="label">4.4.2.</span> <span class="title">
<div class="section" id="sec-stream-state"> <tt>&lt;fstream&gt;</tt> does
<h2 class="title" style="clear: all"> not define <b>std::cout</b>,
<a name="sec-stream-state"><b>7. <b>std::cin</b> etc.</span>
State of streams </h3></div></div>
</b></a> <p>
</h2> In earlier versions of the standard,
<p> <tt>&lt;fstream.h&gt;</tt>,
At least some older implementations don't have <tt>&lt;ostream.h&gt;</tt>
<b>std::ios_base</b>, so you should use and <tt>&lt;istream.h&gt;</tt>
<b>std::ios::badbit</b>, <b>std::ios::failbit</b> used to define
and <b>std::ios::eofbit</b> and <b>cout</b>, <b>cin</b> and so on. Because
<b>std::ios::goodbit</b>. of the templatized iostreams in libstdc++-v3, you need to include
</p> <tt>&lt;iostream&gt;</tt>
</div> explicitly to define these.
<div class="section" id="sec-vector-at"> </p>
<h2 class="title" style="clear: all"> </div>
<a name="sec-vector-at"><b>8. vector::at is missing (i.e. gcc 2.95.2)</b></a> </div>
</h2> <div class="section">
<p> <a name="sec-iterators"></a>
For my use, I added it to <div class="titlepage"><div><h2 class="title" style="clear: all">
<tt>prefix/include/g++-3/stl_vector.h</tt>: <a name="sec-iterators"></a>
<pre class="programlisting"> <span class="label">5.</span> <span class="title">Iterators</span>
reference operator[](size_type __n) { return *(begin() + __n); } </h2></div></div>
reference at(size_type __n) { <p>
if (begin() + __n &gt;= end()) The following are not proper uses of iterators, but may be working
throw out_of_range("vector::at"); fixes for existing uses of iterators.
return *(begin() + __n); <div class="itemizedlist"><ul>
} <li><p>
const_reference operator[](size_type __n) const { return *(begin() + __n); } <a name="id2664787"></a>you cannot do
const_reference at(size_type __n) const { <b>ostream::operator&lt;&lt;(iterator)</b> to
if (begin() + __n &gt;= end()) print the address of the iterator =&gt; use
throw out_of_range("vector::at"); <b>operator&lt;&lt; &amp;*iterator</b> instead ?
return *(begin() + __n); </p></li>
} <li><p>
</pre> <a name="id2664753"></a>you cannot clear an iterator's reference
</p> (<b>iterator = 0</b>) =&gt; use
</div> <b>iterator = iterator_type();</b> ?
<div class="section" id="sec-eof"> </p></li>
<h2 class="title" style="clear: all"> <li><p>
<a name="sec-eof"><b>9. Using std::char_traits&lt;char&gt;::eof()</b></a> <a name="id2664806"></a>
</h2> <b>if (iterator)</b> won't work any
<p> more =&gt; use <b>if (iterator != iterator_type())</b>
<pre class="programlisting"> ?</p></li>
#ifdef HAVE_CHAR_TRAITS </ul></div>
#define CPP_EOF std::char_traits&lt;char&gt;::eof() </p>
#else </div>
#define CPP_EOF EOF <div class="section">
#endif <a name="sec-macros"></a>
</pre> <div class="titlepage"><div><h2 class="title" style="clear: all">
</p> <a name="sec-macros"></a>
</div> <span class="label">6.</span> <span class="title">
<div class="section" id="sec-string-clear"> Libc-macros (i.e. <b>isspace</b> from
<h2 class="title" style="clear: all"> <tt>&lt;cctype&gt;</tt>)</span>
<a name="sec-string-clear"><b>10. Using string::clear()/string::erase()</b></a> </h2></div></div>
</h2> <p>
<p> Glibc 2.0.x and 2.1.x define the <tt>&lt;ctype.h&gt;</tt> -functionality as
There are two functions for deleting the contents of a string: macros (isspace, isalpha etc.). Libstdc++-v3 &quot;shadows&quot; these macros
<b>clear</b> and <b>erase</b> (the latter as described in the <a href="#sec-cheaders"></a>.
returns the string). </p>
<pre class="programlisting"> <p>
void Older implementations of libstdc++ (g++-2 for egcs 1.x and g++-3
clear() { _M_mutate(0, this-&gt;size(), 0); } for gcc 2.95.x), however, keep these functions as macros, and so it
</pre> is not back-portable to use fully qualified names. For example:
<pre class="programlisting"> <pre class="programlisting">
basic_string&amp; #include &lt;cctype&gt;
erase(size_type __pos = 0, size_type __n = npos) int main() { std::isspace('X'); }
{ </pre>
return this-&gt;replace(_M_check(__pos), _M_fold(__pos, __n), will result in something like this (unless using g++-v3):
_M_data(), _M_data()); <pre class="programlisting">
} std:: (__ctype_b[(int) ( ( 'X' ) )] &amp; (unsigned short int)
</pre> _ISspace ) ;
The implementation of <b>erase</b> seems to be more </pre>
complicated (from libstdc++-v3), but <b>clear</b> is not </p>
implemented in gcc 2.95.2's libstdc++, so you should use <p>
<b>erase</b> (which is probably faster than One solution I can think of is to test for -v3 using
<b>operator=(charT*)</b>). autoconf-macros, and define macros for each of the C-functions
</p> (maybe that is possible with one &quot;wrapper&quot; macro as well ?).
</div> </p>
<div class="section" id="sec-stringstream"> <p>
<h2 class="title" style="clear: all"> Another solution which would fix g++ is to tell the user to modify a
<a name="sec-stringstream"><b>11. Using stringstream's</b></a> header-file so that g++-2 (egcs 1.x) and g++-3 (gcc 2.95.x) define a
</h2> macro which tells <tt>&lt;ctype.h&gt;</tt> to define functions
<p> instead of macros:
Libstdc++-v3 includes the new <pre class="programlisting">
<b>i/ostringstream</b>-classes, (<tt>&lt;sstream&gt;</tt>), but with older // This keeps isalnum, et al from being propagated as macros.
implementations you still have to use <b>i/ostrstream</b> #if __linux__
(<tt>&lt;strstream&gt;</tt>): #define __NO_CTYPE 1
<pre class="programlisting"> #endif
#ifdef HAVE_SSTREAM
#include &lt;sstream&gt; [ now include &lt;ctype.h&gt; ]
#else </pre>
#include &lt;strstream&gt; </p>
#endif <p>
</pre> Another problem arises if you put a <b>using namespace
<div class="itemizedlist"> std;</b> declaration at the top, and include <tt>&lt;ctype.h&gt;</tt>. This will result in
<ul> ambiguities between the definitions in the global namespace
<li> (<tt>&lt;ctype.h&gt;</tt>) and the
<a name="N3595"></a> definitions in namespace <b>std::</b>
<p> <b>strstream</b> is considered to be (<b>&lt;cctype&gt;</b>).
deprecated </p>
</p> <p>
</li> The solution to this problem was posted to the libstdc++-v3
<li> mailing-list:
<a name="N3603"></a> Benjamin Kosnik <tt>&lt;<a href="mailto:bkoz@redhat.com">bkoz@redhat.com</a>&gt;</tt> writes:
<p> <b>strstream</b> is limited to `
<b>char</b> --enable-cshadow-headers is currently broken. As a result, shadow
</p> headers are not being searched....
</li> '
<li> </p>
<a name="N3614"></a> </div>
<p> with <b>ostringstream</b> you don't <div class="section">
have to take care of terminating the string or freeing its <a name="sec-stream-state"></a>
memory <div class="titlepage"><div><h2 class="title" style="clear: all">
</p> <a name="sec-stream-state"></a>
</li> <span class="label">7.</span> <span class="title">
<li> State of streams
<a name="N3622"></a> </span>
<p> <b>istringstream</b> can be re-filled </h2></div></div>
(clear(); str(input);) <p>
</p> At least some older implementations don't have
</li> <b>std::ios_base</b>, so you should use
</ul> <b>std::ios::badbit</b>, <b>std::ios::failbit</b>
</div> and <b>std::ios::eofbit</b> and
</p> <b>std::ios::goodbit</b>.
<p> </p>
You can then use output-stringstreams like this: </div>
<pre class="programlisting"> <div class="section">
#ifdef HAVE_SSTREAM <a name="sec-vector-at"></a>
std::ostringstream oss; <div class="titlepage"><div><h2 class="title" style="clear: all">
#else <a name="sec-vector-at"></a>
std::ostrstream oss; <span class="label">8.</span> <span class="title">vector::at is missing (i.e. gcc 2.95.x)</span>
#endif </h2></div></div>
oss &lt;&lt; "Name=" &lt;&lt; m_name &lt;&lt; ", number=" &lt;&lt; m_number &lt;&lt; std::endl; <p>
... You could easily modify the header-files:
#ifndef HAVE_SSTREAM <tt>prefix/include/g++-3/stl_vector.h</tt>:
oss &lt;&lt; std::ends; // terminate the char*-string <pre class="programlisting">
#endif reference operator[](size_type __n) { return *(begin() + __n); }
// str() returns char* for ostrstream and a string for ostringstream reference at(size_type __n) {
// this also causes ostrstream to think that the buffer's memory if (begin() + __n &gt;= end())
// is yours throw out_of_range(&quot;vector::at&quot;);
m_label.set_text(oss.str()); return *(begin() + __n);
#ifndef HAVE_SSTREAM }
// let the ostrstream take care of freeing the memory const_reference operator[](size_type __n) const { return *(begin() + __n); }
oss.freeze(false); const_reference at(size_type __n) const {
#endif if (begin() + __n &gt;= end())
</pre> throw out_of_range(&quot;vector::at&quot;);
</p> return *(begin() + __n);
<p> }
Input-stringstreams can be used similarly: </pre>
<pre class="programlisting"> (and so on for <b>deque</b> and <b>string</b>)
std::string input;
... Of course a better solution is to add an autoconf-test for this:
#ifdef HAVE_SSTREAM <pre class="programlisting">
std::istringstream iss(input); AC_MSG_CHECKING(for container::at)
#else AC_TRY_COMPILE(
std::istrstream iss(input.c_str()); [
#endif #include &lt;vector&gt;
int i; #include &lt;deque&gt;
iss &gt;&gt; i; #include &lt;string&gt;
</pre>
One (the only?) restriction is that an istrstream cannot be re-filled: using namespace std;
<pre class="programlisting"> ],
std::istringstream iss(numerator); [
iss &gt;&gt; m_num; deque&lt;int&gt; test_deque(3);
// this is not possible with istrstream test_deque.at(2);
iss.clear(); vector&lt;int&gt; test_vector(2);
iss.str(denominator); test_vector.at(1);
iss &gt;&gt; m_den; string test_string(&quot;test_string&quot;);
</pre> test_string.at(3);
If you don't care about speed, you can put these conversions in ],
a template-function: [AC_MSG_RESULT(yes)
<pre class="programlisting"> AC_DEFINE(HAVE_CONTAINER_AT)],
template &lt;class X&gt; [AC_MSG_RESULT(no)])
void fromString(const string&amp; input, X&amp; any) </pre>
{ If you are using other (non-GNU) compilers it might be a good idea
#ifdef HAVE_SSTREAM to check for <b>string::at</b> separately.
std::istringstream iss(input); </p>
#else </div>
std::istrstream iss(input.c_str()); <div class="section">
#endif <a name="sec-eof"></a>
X temp; <div class="titlepage"><div><h2 class="title" style="clear: all">
iss &gt;&gt; temp; <a name="sec-eof"></a>
if (iss.fail()) <span class="label">9.</span> <span class="title">Using std::char_traits&lt;char&gt;::eof()</span>
throw runtime_error(..) </h2></div></div>
any = temp; <p>
} <pre class="programlisting">
</pre> #ifdef HAVE_CHAR_TRAITS
</p> #define CPP_EOF std::char_traits&lt;char&gt;::eof()
<p> #else
I have read the Josuttis book on Standard C++, so some information #define CPP_EOF EOF
comes from there. Additionally, there is information in #endif
"info iostream", which covers the old implementation that gcc 2.95.2 </pre>
uses. </p>
</p> </div>
</div> <div class="section">
<div class="section" id="sec-about"> <a name="sec-string-clear"></a>
<h2 class="title" style="clear: all"> <div class="titlepage"><div><h2 class="title" style="clear: all">
<a name="sec-about"><b>12. About...</b></a> <a name="sec-string-clear"></a>
</h2> <span class="label">10.</span> <span class="title">Using string::clear()/string::erase()</span>
<p> </h2></div></div>
Please send any experience, additions, corrections or questions to <p>
<a href="mailto:fnatter@gmx.net">fnatter@gmx.net</a> or for There are two functions for deleting the contents of a string:
discussion to the libstdc++-v3-mailing-list. <b>clear</b> and <b>erase</b> (the latter
</p> returns the string).
</div> <pre class="programlisting">
</div> void
</body> clear() { _M_mutate(0, this-&gt;size(), 0); }
</pre>
<pre class="programlisting">
basic_string&amp;
erase(size_type __pos = 0, size_type __n = npos)
{
return this-&gt;replace(_M_check(__pos), _M_fold(__pos, __n),
_M_data(), _M_data());
}
</pre>
The implementation of <b>erase</b> seems to be more
complicated (from libstdc++-v3), but <b>clear</b> is not
implemented in gcc 2.95.x's libstdc++, so you should use
<b>erase</b> (which is probably faster than
<b>operator=(charT*)</b>).
</p>
</div>
<div class="section">
<a name="sec-stringstream"></a>
<div class="titlepage"><div><h2 class="title" style="clear: all">
<a name="sec-stringstream"></a>
<span class="label">11.</span> <span class="title">Using stringstream's</span>
</h2></div></div>
<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>
(<tt>&lt;strstream&gt;</tt>):
<pre class="programlisting">
#ifdef HAVE_SSTREAM
#include &lt;sstream&gt;
#else
#include &lt;strstream&gt;
#endif
</pre>
<div class="itemizedlist"><ul>
<li><p>
<a name="id2665237"></a> <b>strstream</b> is considered to be
deprecated
</p></li>
<li><p>
<a name="id2665256"></a> <b>strstream</b> is limited to
<b>char</b>
</p></li>
<li><p>
<a name="id2665271"></a> with <b>ostringstream</b> you don't
have to take care of terminating the string or freeing its
memory
</p></li>
<li><p>
<a name="id2665284"></a> <b>istringstream</b> can be re-filled
(clear(); str(input);)
</p></li>
</ul></div>
</p>
<p>
You can then use output-stringstreams like this:
<pre class="programlisting">
#ifdef HAVE_SSTREAM
std::ostringstream oss;
#else
std::ostrstream oss;
#endif
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
oss &lt;&lt; std::ends; // terminate the char*-string
#endif
// str() returns char* for ostrstream and a string for ostringstream
// this also causes ostrstream to think that the buffer's memory
// is yours
m_label.set_text(oss.str());
#ifndef HAVE_SSTREAM
// let the ostrstream take care of freeing the memory
oss.freeze(false);
#endif
</pre>
</p>
<p>
Input-stringstreams can be used similarly:
<pre class="programlisting">
std::string input;
...
#ifdef HAVE_SSTREAM
std::istringstream iss(input);
#else
std::istrstream iss(input.c_str());
#endif
int i;
iss &gt;&gt; i;
</pre>
One (the only?) restriction is that an istrstream cannot be re-filled:
<pre class="programlisting">
std::istringstream iss(numerator);
iss &gt;&gt; m_num;
// this is not possible with istrstream
iss.clear();
iss.str(denominator);
iss &gt;&gt; m_den;
</pre>
If you don't care about speed, you can put these conversions in
a template-function:
<pre class="programlisting">
template &lt;class X&gt;
void fromString(const string&amp; input, X&amp; any)
{
#ifdef HAVE_SSTREAM
std::istringstream iss(input);
#else
std::istrstream iss(input.c_str());
#endif
X temp;
iss &gt;&gt; temp;
if (iss.fail())
throw runtime_error(..)
any = temp;
}
</pre>
</p>
<p>
I have read the Josuttis book on Standard C++, so some information
comes from there. Additionally, there is information in
&quot;info iostream&quot;, which covers the old implementation that gcc 2.95.x
uses.
</p>
</div>
<div class="section">
<a name="sec-about"></a>
<div class="titlepage"><div><h2 class="title" style="clear: all">
<a name="sec-about"></a>
<span class="label">12.</span> <span class="title">About...</span>
</h2></div></div>
<p>
Please send any experience, additions, corrections or questions to
<a href="mailto:fnatter@gmx.net" target="_top">fnatter@gmx.net</a> or for
discussion to the libstdc++-v3-mailing-list.
</p>
</div>
</div></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