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