1*404b540aSrobert<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> 2*404b540aSrobert<html> 3*404b540aSrobert<head> 4*404b540aSrobert<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> 5*404b540aSrobert<title>Libstdc++-porting-howto</title> 6*404b540aSrobert<meta name="generator" content="DocBook XSL Stylesheets V1.48"> 7*404b540aSrobert</head> 8*404b540aSrobert<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="article"> 9*404b540aSrobert<div class="titlepage"> 10*404b540aSrobert<div><h1 class="title"> 11*404b540aSrobert<a name="libstdc++-porting-howto"></a>Libstdc++-porting-howto</h1></div> 12*404b540aSrobert<div><h3 class="author">Felix Natter</h3></div> 13*404b540aSrobert<div><div class="legalnotice"> 14*404b540aSrobert<p class="legalnotice-title"><b>Legal Notice</b></p> 15*404b540aSrobert<p> 16*404b540aSrobert This document can be distributed under the FDL 17*404b540aSrobert (<a href="http://www.gnu.org" target="_top">www.gnu.org</a>) 18*404b540aSrobert </p> 19*404b540aSrobert</div></div> 20*404b540aSrobert<div><p class="pubdate">Tue Jun 5 20:07:49 2001</p></div> 21*404b540aSrobert<div><div class="revhistory"><table border="1" width="100%" summary="Revision history"> 22*404b540aSrobert<tr><th align="left" valign="top" colspan="3"><b>Revision History</b></th></tr> 23*404b540aSrobert<tr> 24*404b540aSrobert<td align="left">Revision 0.5</td> 25*404b540aSrobert<td align="left">Thu Jun 1 13:06:50 2000</td> 26*404b540aSrobert<td align="left">fnatter</td> 27*404b540aSrobert</tr> 28*404b540aSrobert<tr><td align="left" colspan="3">First docbook-version.</td></tr> 29*404b540aSrobert<tr> 30*404b540aSrobert<td align="left">Revision 0.8</td> 31*404b540aSrobert<td align="left">Sun Jul 30 20:28:40 2000</td> 32*404b540aSrobert<td align="left">fnatter</td> 33*404b540aSrobert</tr> 34*404b540aSrobert<tr><td align="left" colspan="3">First released version using docbook-xml 35*404b540aSrobert + second upload to libstdc++-page. 36*404b540aSrobert </td></tr> 37*404b540aSrobert<tr> 38*404b540aSrobert<td align="left">Revision 0.9</td> 39*404b540aSrobert<td align="left">Wed Sep 6 02:59:32 2000</td> 40*404b540aSrobert<td align="left">fnatter</td> 41*404b540aSrobert</tr> 42*404b540aSrobert<tr><td align="left" colspan="3">5 new sections.</td></tr> 43*404b540aSrobert<tr> 44*404b540aSrobert<td align="left">Revision 0.9.1</td> 45*404b540aSrobert<td align="left">Sat Sep 23 14:20:15 2000</td> 46*404b540aSrobert<td align="left">fnatter</td> 47*404b540aSrobert</tr> 48*404b540aSrobert<tr><td align="left" colspan="3">added information about why file-descriptors are not in the 49*404b540aSrobert standard</td></tr> 50*404b540aSrobert<tr> 51*404b540aSrobert<td align="left">Revision 0.9.2</td> 52*404b540aSrobert<td align="left">Tue Jun 5 20:07:49 2001</td> 53*404b540aSrobert<td align="left">fnatter</td> 54*404b540aSrobert</tr> 55*404b540aSrobert<tr><td align="left" colspan="3"> 56*404b540aSrobert a fix, added hint on increased portability of C-shadow-headers, 57*404b540aSrobert added autoconf-test HAVE_CONTAINER_AT 58*404b540aSrobert </td></tr> 59*404b540aSrobert<tr> 60*404b540aSrobert<td align="left">Revision 0.9.3</td> 61*404b540aSrobert<td align="left">Fri Jun 29 16:15:56 2001</td> 62*404b540aSrobert<td align="left">fnatter</td> 63*404b540aSrobert</tr> 64*404b540aSrobert<tr><td align="left" colspan="3"> 65*404b540aSrobert changed signature of nonstandard filebuf-constructor and 66*404b540aSrobert update the section on filebuf::attach to point to ../ext/howto.html, 67*404b540aSrobert added link to ../21/strings/howto.html 68*404b540aSrobert in sec-stringstream, changed <link>-tags to have content 69*404b540aSrobert (so that these links work), 70*404b540aSrobert replace "user-space" by "global namespace" 71*404b540aSrobert add note about gcc 3.0 and shadow-headers 72*404b540aSrobert add section about ostream::form and istream::scan 73*404b540aSrobert sec-vector-at: remove hint to modify headers 74*404b540aSrobert fix spelling error in sec-stringstream 75*404b540aSrobert </td></tr> 76*404b540aSrobert<tr> 77*404b540aSrobert<td align="left">Revision 0.9.4</td> 78*404b540aSrobert<td align="left">Mon Nov 5 17:01:04 2001</td> 79*404b540aSrobert<td align="left">fnatter</td> 80*404b540aSrobert</tr> 81*404b540aSrobert<tr><td align="left" colspan="3"> 82*404b540aSrobert rewrite section 1.1.3 because of gnu.gcc.help-post by 83*404b540aSrobert Juergen Heinzl 84*404b540aSrobert </td></tr> 85*404b540aSrobert</table></div></div> 86*404b540aSrobert<div><div class="abstract"> 87*404b540aSrobert<p><b>Abstract</b></p> 88*404b540aSrobert<p> 89*404b540aSrobert Some notes on porting applications from libstdc++-2.90 (or earlier 90*404b540aSrobert versions) to libstdc++-v3. Not speaking in terms of the GNU libstdc++ 91*404b540aSrobert implementations, this means porting from earlier versions of the 92*404b540aSrobert C++-Standard to ISO 14882. 93*404b540aSrobert </p> 94*404b540aSrobert</div></div> 95*404b540aSrobert<hr> 96*404b540aSrobert</div> 97*404b540aSrobert<div class="toc"> 98*404b540aSrobert<p><b>Table of Contents</b></p> 99*404b540aSrobert<dl> 100*404b540aSrobert<dt>1. <a href="#sec-nsstd">Namespace std::</a> 101*404b540aSrobert</dt> 102*404b540aSrobert<dd><dl> 103*404b540aSrobert<dt>1.1.1. <a href="#sec-gtkmm-hack">Using namespace 104*404b540aSrobert composition if the project uses a separate 105*404b540aSrobert namespace</a> 106*404b540aSrobert</dt> 107*404b540aSrobert<dt>1.1.2. <a href="#sec-emptyns">Defining an empty namespace std</a> 108*404b540aSrobert</dt> 109*404b540aSrobert<dt>1.1.3. <a href="#sec-avoidfqn">Avoid to use fully qualified names 110*404b540aSrobert (i.e. std::string)</a> 111*404b540aSrobert</dt> 112*404b540aSrobert<dt>1.1.4. <a href="#sec-osprojects">How some open-source-projects deal 113*404b540aSrobert with this</a> 114*404b540aSrobert</dt> 115*404b540aSrobert</dl></dd> 116*404b540aSrobert<dt>2. <a href="#sec-nocreate">There is no ios::nocreate/ios::noreplace 117*404b540aSrobert in ISO 14882</a> 118*404b540aSrobert</dt> 119*404b540aSrobert<dt>3. <a href="#sec-stream::attach">stream::attach(int 120*404b540aSrobert fd) is not in the standard any more</a> 121*404b540aSrobert</dt> 122*404b540aSrobert<dt>4. <a href="#sec-headers">The new headers</a> 123*404b540aSrobert</dt> 124*404b540aSrobert<dd><dl> 125*404b540aSrobert<dt>4.4.1. <a href="#sec-cheaders">New headers replacing C-headers</a> 126*404b540aSrobert</dt> 127*404b540aSrobert<dt>4.4.2. <a href="#sec-fstream-header"> 128*404b540aSrobert <fstream> does 129*404b540aSrobert not define std::cout, 130*404b540aSrobert std::cin etc.</a> 131*404b540aSrobert</dt> 132*404b540aSrobert</dl></dd> 133*404b540aSrobert<dt>5. <a href="#sec-iterators">Iterators</a> 134*404b540aSrobert</dt> 135*404b540aSrobert<dt>6. <a href="#sec-macros"> 136*404b540aSrobert Libc-macros (i.e. isspace from 137*404b540aSrobert <cctype>)</a> 138*404b540aSrobert</dt> 139*404b540aSrobert<dt>7. <a href="#sec-stream-state">State of streams</a> 140*404b540aSrobert</dt> 141*404b540aSrobert<dt>8. <a href="#sec-vector-at">vector::at is missing (i.e. gcc 2.95.x)</a> 142*404b540aSrobert</dt> 143*404b540aSrobert<dt>9. <a href="#sec-eof">Using std::char_traits<char>::eof()</a> 144*404b540aSrobert</dt> 145*404b540aSrobert<dt>10. <a href="#sec-string-clear">Using string::clear()/string::erase()</a> 146*404b540aSrobert</dt> 147*404b540aSrobert<dt>11. <a href="#sec-scan-form">GNU Extensions ostream::form and istream::scan</a> 148*404b540aSrobert</dt> 149*404b540aSrobert<dt>12. <a href="#sec-stringstream">Using stringstreams</a> 150*404b540aSrobert</dt> 151*404b540aSrobert<dt>13. <a href="#sec-about">About...</a> 152*404b540aSrobert</dt> 153*404b540aSrobert</dl> 154*404b540aSrobert</div> 155*404b540aSrobert<p> 156*404b540aSrobert In the following, when I say portable, I will refer to "portable among ISO 157*404b540aSrobert 14882-implementations". On the other hand, if I say "backportable" or 158*404b540aSrobert "conservative", I am talking about "compiles with older 159*404b540aSrobert libstdc++-implementations". 160*404b540aSrobert </p> 161*404b540aSrobert<div class="section"> 162*404b540aSrobert<div class="titlepage"><div><h2 class="title" style="clear: both"> 163*404b540aSrobert<a name="sec-nsstd"></a>Namespace std::</h2></div></div> 164*404b540aSrobert<p> 165*404b540aSrobert The latest C++-standard (ISO-14882) requires that the standard 166*404b540aSrobert C++-library is defined in namespace std::. Thus, in order to use 167*404b540aSrobert classes from the standard C++-library, you can do one of three 168*404b540aSrobert things: 169*404b540aSrobert <div class="itemizedlist"><ul type="disc"> 170*404b540aSrobert<li><p>wrap your code in <b>namespace std { 171*404b540aSrobert ... }</b> => This is not an option because only symbols 172*404b540aSrobert from the standard c++-library are defined in namespace std::. 173*404b540aSrobert </p></li> 174*404b540aSrobert<li><p>put a kind of 175*404b540aSrobert <span class="emphasis"><i>using-declaration</i></span> in your source (either 176*404b540aSrobert <b>using namespace std;</b> or i.e. <b>using 177*404b540aSrobert std::string;</b>) => works well for source-files, but 178*404b540aSrobert cannot be used in header-files. 179*404b540aSrobert </p></li> 180*404b540aSrobert<li><p>use a <span class="emphasis"><i>fully qualified name</i></span> for 181*404b540aSrobert each libstdc++-symbol (i.e. <b>std::string</b>, 182*404b540aSrobert <b>std::cout</b>) => can always be used 183*404b540aSrobert </p></li> 184*404b540aSrobert</ul></div> 185*404b540aSrobert<p> 186*404b540aSrobert Because there are many compilers which still use an implementation 187*404b540aSrobert that does not have the standard C++-library in namespace 188*404b540aSrobert <b>std::</b>, some care is required to support these as 189*404b540aSrobert well. 190*404b540aSrobert </p> 191*404b540aSrobert<p> 192*404b540aSrobert Namespace back-portability-issues are generally not a problem with 193*404b540aSrobert g++, because versions of g++ that do not have libstdc++ in 194*404b540aSrobert <b>std::</b> use <b>-fno-honor-std</b> 195*404b540aSrobert (ignore <b>std::</b>, <b>:: = std::</b>) by 196*404b540aSrobert default. That is, the responsibility for enabling or disabling 197*404b540aSrobert <b>std::</b> is on the user; the maintainer does not have 198*404b540aSrobert to care about it. This probably applies to some other compilers as 199*404b540aSrobert well. 200*404b540aSrobert </p> 201*404b540aSrobert<p> 202*404b540aSrobert The following sections list some possible solutions to support compilers 203*404b540aSrobert that cannot ignore std::. 204*404b540aSrobert </p> 205*404b540aSrobert<div class="section"> 206*404b540aSrobert<div class="titlepage"><div><h3 class="title"> 207*404b540aSrobert<a name="sec-gtkmm-hack"></a>Using <span class="emphasis"><i>namespace 208*404b540aSrobert composition</i></span> if the project uses a separate 209*404b540aSrobert namespace</h3></div></div> 210*404b540aSrobert<p> 211*404b540aSrobert <a href="http://gtkmm.sourceforge.net" target="_top">Gtk--</a> defines 212*404b540aSrobert most of its classes in namespace Gtk::. Thus, it was possible to 213*404b540aSrobert adapt Gtk-- to namespace std:: by using a C++-feature called 214*404b540aSrobert <span class="emphasis"><i>namespace composition</i></span>. This is what happens if 215*404b540aSrobert you put a <span class="emphasis"><i>using</i></span>-declaration into a 216*404b540aSrobert namespace-definition: the imported symbol(s) gets imported into the 217*404b540aSrobert currently active namespace(s). For example: 218*404b540aSrobert <pre class="programlisting"> 219*404b540aSrobert namespace Gtk { 220*404b540aSrobert using std::string; 221*404b540aSrobert class Window { ... } 222*404b540aSrobert } 223*404b540aSrobert </pre> 224*404b540aSrobert In this example, <b>std::string</b> gets imported into 225*404b540aSrobert namespace Gtk::. The result is that you don't have to use 226*404b540aSrobert <b>std::string</b> in this header, but still 227*404b540aSrobert <b>std::string</b> does not get imported into 228*404b540aSrobert the global namespace (::) unless the user does 229*404b540aSrobert <b>using namespace Gtk;</b> (which is not recommended 230*404b540aSrobert practice for Gtk--, so it is not a problem). Additionally, the 231*404b540aSrobert <b>using</b>-declarations are wrapped in macros that 232*404b540aSrobert are set based on autoconf-tests to either "" or i.e. <b>using 233*404b540aSrobert std::string;</b> (depending on whether the system has 234*404b540aSrobert libstdc++ in <b>std::</b> or not). (ideas from 235*404b540aSrobert <tt><<a href="mailto:llewelly@dbritsch.dsl.xmission.com">llewelly@dbritsch.dsl.xmission.com</a>></tt>, Karl Nelson 236*404b540aSrobert <tt><<a href="mailto:kenelson@ece.ucdavis.edu">kenelson@ece.ucdavis.edu</a>></tt>) 237*404b540aSrobert</div> 238*404b540aSrobert<div class="section"> 239*404b540aSrobert<div class="titlepage"><div><h3 class="title"> 240*404b540aSrobert<a name="sec-emptyns"></a>Defining an empty namespace std</h3></div></div> 241*404b540aSrobert<p> 242*404b540aSrobert By defining an (empty) namespace <b>std::</b> before 243*404b540aSrobert using it, you avoid getting errors on systems where no part of the 244*404b540aSrobert library is in namespace std: 245*404b540aSrobert <pre class="programlisting"> 246*404b540aSrobert namespace std { } 247*404b540aSrobert using namespace std; 248*404b540aSrobert </pre> 249*404b540aSrobert</div> 250*404b540aSrobert<div class="section"> 251*404b540aSrobert<div class="titlepage"><div><h3 class="title"> 252*404b540aSrobert<a name="sec-avoidfqn"></a>Avoid to use fully qualified names 253*404b540aSrobert (i.e. std::string)</h3></div></div> 254*404b540aSrobert<p> 255*404b540aSrobert If some compilers complain about <b>using 256*404b540aSrobert std::string;</b>, and if the "hack" for gtk-- mentioned above 257*404b540aSrobert does not work, then I see two solutions: 258*404b540aSrobert 259*404b540aSrobert <div class="itemizedlist"><ul type="disc"> 260*404b540aSrobert<li><p> 261*404b540aSrobert Define <b>std::</b> as a macro if the compiler 262*404b540aSrobert doesn't know about <b>std::</b>. 263*404b540aSrobert <pre class="programlisting"> 264*404b540aSrobert #ifdef OLD_COMPILER 265*404b540aSrobert #define std 266*404b540aSrobert #endif 267*404b540aSrobert </pre> 268*404b540aSrobert (thanks to Juergen Heinzl who posted this solution on 269*404b540aSrobert gnu.gcc.help) 270*404b540aSrobert </li> 271*404b540aSrobert<li><p> 272*404b540aSrobert Define a macro NS_STD, which is defined to 273*404b540aSrobert either "" or "std" 274*404b540aSrobert based on an autoconf-test. Then you should be able to use 275*404b540aSrobert <b>NS_STD::string</b>, which will evaluate to 276*404b540aSrobert <b>::string</b> ("string in the global namespace") on 277*404b540aSrobert systems that do not put string in std::. (This is untested) 278*404b540aSrobert </p></li> 279*404b540aSrobert</ul></div> 280*404b540aSrobert</div> 281*404b540aSrobert<div class="section"> 282*404b540aSrobert<div class="titlepage"><div><h3 class="title"> 283*404b540aSrobert<a name="sec-osprojects"></a>How some open-source-projects deal 284*404b540aSrobert with this</h3></div></div> 285*404b540aSrobert<p> 286*404b540aSrobert This information was gathered around May 2000. It may not be correct 287*404b540aSrobert by the time you read this. 288*404b540aSrobert </p> 289*404b540aSrobert<div class="table"> 290*404b540aSrobert<p><b>Table 1. Namespace std:: in Open-Source programs</b></p> 291*404b540aSrobert<table summary="Namespace std:: in Open-Source programs" border="1"> 292*404b540aSrobert<colgroup> 293*404b540aSrobert<col> 294*404b540aSrobert<col> 295*404b540aSrobert</colgroup> 296*404b540aSrobert<tbody> 297*404b540aSrobert<tr> 298*404b540aSrobert<td><a href="http://www.clanlib.org" target="_top">clanlib</a></td> 299*404b540aSrobert<td>usual</td> 300*404b540aSrobert</tr> 301*404b540aSrobert<tr> 302*404b540aSrobert<td><a href="http://pingus.seul.org" target="_top">pingus</a></td> 303*404b540aSrobert<td>usual</td> 304*404b540aSrobert</tr> 305*404b540aSrobert<tr> 306*404b540aSrobert<td><a href="http://www.mozilla.org" target="_top">mozilla</a></td> 307*404b540aSrobert<td>usual</td> 308*404b540aSrobert</tr> 309*404b540aSrobert<tr> 310*404b540aSrobert<td><a href="http://libsigc.sourceforge.net" target="_top"> 311*404b540aSrobert libsigc++</a></td> 312*404b540aSrobert<td>conservative-impl</td> 313*404b540aSrobert</tr> 314*404b540aSrobert</tbody> 315*404b540aSrobert</table> 316*404b540aSrobert</div> 317*404b540aSrobert<div class="table"> 318*404b540aSrobert<p><b>Table 2. Notations for categories</b></p> 319*404b540aSrobert<table summary="Notations for categories" border="1"> 320*404b540aSrobert<colgroup> 321*404b540aSrobert<col> 322*404b540aSrobert<col> 323*404b540aSrobert</colgroup> 324*404b540aSrobert<tbody> 325*404b540aSrobert<tr> 326*404b540aSrobert<td>usual</td> 327*404b540aSrobert<td>mostly fully qualified names and some 328*404b540aSrobert using-declarations (but not in headers)</td> 329*404b540aSrobert</tr> 330*404b540aSrobert<tr> 331*404b540aSrobert<td>none</td> 332*404b540aSrobert<td>no namespace std at all</td> 333*404b540aSrobert</tr> 334*404b540aSrobert<tr> 335*404b540aSrobert<td>conservative-impl</td> 336*404b540aSrobert<td>wrap all 337*404b540aSrobert namespace-handling in macros to support compilers without 338*404b540aSrobert namespace-support (no libstdc++ used in headers)</td> 339*404b540aSrobert</tr> 340*404b540aSrobert</tbody> 341*404b540aSrobert</table> 342*404b540aSrobert</div> 343*404b540aSrobert<p> 344*404b540aSrobert As you can see, this currently lacks an example of a project 345*404b540aSrobert which uses libstdc++-symbols in headers in a back-portable way 346*404b540aSrobert (except for Gtk--: see the <a href="#sec-gtkmm-hack" title="Using namespace 347*404b540aSrobert composition if the project uses a separate 348*404b540aSrobert namespace">section on the gtkmm-hack</a>). 349*404b540aSrobert </p> 350*404b540aSrobert</div> 351*404b540aSrobert</div> 352*404b540aSrobert<div class="section"> 353*404b540aSrobert<div class="titlepage"><div><h2 class="title" style="clear: both"> 354*404b540aSrobert<a name="sec-nocreate"></a>There is no ios::nocreate/ios::noreplace 355*404b540aSrobert in ISO 14882</h2></div></div> 356*404b540aSrobert<p> 357*404b540aSrobert I have seen <b>ios::nocreate</b> being used for 358*404b540aSrobert input-streams, most probably because the author thought it would be 359*404b540aSrobert more correct to specify nocreate "explicitly". So you can simply 360*404b540aSrobert leave it out for input-streams. 361*404b540aSrobert </p> 362*404b540aSrobert<p> 363*404b540aSrobert For output streams, "nocreate" is probably the default, unless you 364*404b540aSrobert specify <b>std::ios::trunc</b> ? To be safe, you can open 365*404b540aSrobert the file for reading, check if it has been opened, and then decide 366*404b540aSrobert whether you want to create/replace or not. To my knowledge, even 367*404b540aSrobert older implementations support <b>app</b>, 368*404b540aSrobert <b>ate</b> and <b>trunc</b> (except for 369*404b540aSrobert <b>app</b> ?). 370*404b540aSrobert </p> 371*404b540aSrobert</div> 372*404b540aSrobert<div class="section"> 373*404b540aSrobert<div class="titlepage"><div><h2 class="title" style="clear: both"> 374*404b540aSrobert<a name="sec-stream::attach"></a><b>stream::attach(int 375*404b540aSrobert fd)</b> is not in the standard any more</h2></div></div> 376*404b540aSrobert<p> 377*404b540aSrobert Phil Edwards <tt><<a href="mailto:pedwards@disaster.jaj.com">pedwards@disaster.jaj.com</a>></tt> writes: 378*404b540aSrobert It was considered and rejected. Not all environments use file 379*404b540aSrobert descriptors. Of those that do, not all of them use integers to represent 380*404b540aSrobert them. 381*404b540aSrobert </p> 382*404b540aSrobert 383*404b540aSrobert<p> 384*404b540aSrobert For a portable solution (among systems which use 385*404b540aSrobert filedescriptors), you need to implement a subclass of 386*404b540aSrobert <b>std::streambuf</b> (or 387*404b540aSrobert <b>std::basic_streambuf<..></b>) which opens a file 388*404b540aSrobert given a descriptor, and then pass an instance of this to the 389*404b540aSrobert stream-constructor. For an example of this, refer to 390*404b540aSrobert <a href="http://www.josuttis.com/cppcode/fdstream.html" target="_top">fdstream example</a> 391*404b540aSrobert by Nicolai Josuttis. 392*404b540aSrobert </p> 393*404b540aSrobert 394*404b540aSrobert<p> 395*404b540aSrobert An extension is also available: 396*404b540aSrobert <code><ext/stdio_filebuf.h></code> contains a derived class called 397*404b540aSrobert <a href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/class____gnu__cxx_1_1stdio__filebuf.html"><code>__gnu_cxx::stdio_filebuf</code></a>. 398*404b540aSrobert This class can be constructed from a C <code>FILE*</code> or a file 399*404b540aSrobert descriptor, and provides the <code>fd()</code> function. 400*404b540aSrobert </p> 401*404b540aSrobert</div> 402*404b540aSrobert<div class="section"> 403*404b540aSrobert<div class="titlepage"><div><h2 class="title" style="clear: both"> 404*404b540aSrobert<a name="sec-headers"></a>The new headers</h2></div></div> 405*404b540aSrobert<p> 406*404b540aSrobert All new headers can be seen in this <a href="headers_cc.txt" target="_top"> 407*404b540aSrobert source-code</a>. 408*404b540aSrobert </p> 409*404b540aSrobert<p> 410*404b540aSrobert The old C++-headers (iostream.h etc.) are available, but gcc generates 411*404b540aSrobert a warning that you are using deprecated headers. 412*404b540aSrobert </p> 413*404b540aSrobert<div class="section"> 414*404b540aSrobert<div class="titlepage"><div><h3 class="title"> 415*404b540aSrobert<a name="sec-cheaders"></a>New headers replacing C-headers</h3></div></div> 416*404b540aSrobert<p> 417*404b540aSrobert You should not use the C-headers (except for system-level 418*404b540aSrobert headers) from C++ programs. Instead, you should use a set of 419*404b540aSrobert headers that are named by prepending 'c' and, as usual, 420*404b540aSrobert omitting the extension (.h). For example, instead of using 421*404b540aSrobert <tt><math.h></tt>, you 422*404b540aSrobert should use <tt><cmath></tt>. In some cases this has 423*404b540aSrobert the advantage that the C++-header is more standardized than 424*404b540aSrobert the C-header (i.e. <tt><ctime></tt> (almost) 425*404b540aSrobert corresponds to either <tt><time.h></tt> or <tt><sys/time.h></tt>). 426*404b540aSrobert 427*404b540aSrobert The standard specifies that if you include the C-style header 428*404b540aSrobert (<tt><math.h></tt> in 429*404b540aSrobert this case), the symbols will be available both in the global 430*404b540aSrobert namespace and in namespace <b>std::</b> (but 431*404b540aSrobert libstdc++ does not yet have fully compliant headers) On the 432*404b540aSrobert other hand, if you include only the new header (i.e. <tt><cmath></tt>), the symbols 433*404b540aSrobert will only be defined in namespace <b>std::</b> 434*404b540aSrobert (and macros will be converted to inline-functions). 435*404b540aSrobert </p> 436*404b540aSrobert<p> 437*404b540aSrobert For more information on this, and for information on how the 438*404b540aSrobert GNU C++ implementation might reuse ("shadow") the C 439*404b540aSrobert library-functions, have a look at <a href="http://www.cantrip.org/cheaders.html" target="_top"> 440*404b540aSrobert www.cantrip.org</a>. 441*404b540aSrobert </p> 442*404b540aSrobert</div> 443*404b540aSrobert<div class="section"> 444*404b540aSrobert<div class="titlepage"><div><h3 class="title"> 445*404b540aSrobert<a name="sec-fstream-header"></a> 446*404b540aSrobert <tt><fstream></tt> does 447*404b540aSrobert not define <b>std::cout</b>, 448*404b540aSrobert <b>std::cin</b> etc.</h3></div></div> 449*404b540aSrobert<p> 450*404b540aSrobert In earlier versions of the standard, 451*404b540aSrobert <tt><fstream.h></tt>, 452*404b540aSrobert <tt><ostream.h></tt> 453*404b540aSrobert and <tt><istream.h></tt> 454*404b540aSrobert used to define 455*404b540aSrobert <b>cout</b>, <b>cin</b> and so on. Because 456*404b540aSrobert of the templatized iostreams in libstdc++-v3, you need to include 457*404b540aSrobert <tt><iostream></tt> 458*404b540aSrobert explicitly to define these. 459*404b540aSrobert </p> 460*404b540aSrobert</div> 461*404b540aSrobert</div> 462*404b540aSrobert<div class="section"> 463*404b540aSrobert<div class="titlepage"><div><h2 class="title" style="clear: both"> 464*404b540aSrobert<a name="sec-iterators"></a>Iterators</h2></div></div> 465*404b540aSrobert<p> 466*404b540aSrobert The following are not proper uses of iterators, but may be working 467*404b540aSrobert fixes for existing uses of iterators. 468*404b540aSrobert <div class="itemizedlist"><ul type="disc"> 469*404b540aSrobert<li><p>you cannot do 470*404b540aSrobert <b>ostream::operator<<(iterator)</b> to 471*404b540aSrobert print the address of the iterator => use 472*404b540aSrobert <b>operator<< &*iterator</b> instead ? 473*404b540aSrobert </p></li> 474*404b540aSrobert<li><p>you cannot clear an iterator's reference 475*404b540aSrobert (<b>iterator = 0</b>) => use 476*404b540aSrobert <b>iterator = iterator_type();</b> ? 477*404b540aSrobert </p></li> 478*404b540aSrobert<li><p> 479*404b540aSrobert<b>if (iterator)</b> won't work any 480*404b540aSrobert more => use <b>if (iterator != iterator_type())</b> 481*404b540aSrobert ?</p></li> 482*404b540aSrobert</ul></div> 483*404b540aSrobert</div> 484*404b540aSrobert<div class="section"> 485*404b540aSrobert<div class="titlepage"><div><h2 class="title" style="clear: both"> 486*404b540aSrobert<a name="sec-macros"></a> 487*404b540aSrobert Libc-macros (i.e. <b>isspace</b> from 488*404b540aSrobert <tt><cctype></tt>)</h2></div></div> 489*404b540aSrobert<p> 490*404b540aSrobert Glibc 2.0.x and 2.1.x define the 491*404b540aSrobert <tt><ctype.h></tt> 492*404b540aSrobert -functionality as macros (isspace, isalpha etc.). Libstdc++-v3 493*404b540aSrobert "shadows" these macros as described in the <a href="#sec-cheaders" title="New headers replacing C-headers">section about 494*404b540aSrobert c-headers</a>. 495*404b540aSrobert </p> 496*404b540aSrobert<p> 497*404b540aSrobert Older implementations of libstdc++ (g++-2 for egcs 1.x and g++-3 498*404b540aSrobert for gcc 2.95.x), however, keep these functions as macros, and so it 499*404b540aSrobert is not back-portable to use fully qualified names. For example: 500*404b540aSrobert <pre class="programlisting"> 501*404b540aSrobert #include <cctype> 502*404b540aSrobert int main() { std::isspace('X'); } 503*404b540aSrobert </pre> 504*404b540aSrobert will result in something like this (unless using g++-v3): 505*404b540aSrobert <pre class="programlisting"> 506*404b540aSrobert std:: (__ctype_b[(int) ( ( 'X' ) )] & (unsigned short int) 507*404b540aSrobert _ISspace ) ; 508*404b540aSrobert </pre> 509*404b540aSrobert<p> 510*404b540aSrobert One solution I can think of is to test for -v3 using 511*404b540aSrobert autoconf-macros, and define macros for each of the C-functions 512*404b540aSrobert (maybe that is possible with one "wrapper" macro as well ?). 513*404b540aSrobert </p> 514*404b540aSrobert<p> 515*404b540aSrobert Another solution which would fix g++ is to tell the user to modify a 516*404b540aSrobert header-file so that g++-2 (egcs 1.x) and g++-3 (gcc 2.95.x) define a 517*404b540aSrobert macro which tells <tt><ctype.h></tt> to define functions 518*404b540aSrobert instead of macros: 519*404b540aSrobert <pre class="programlisting"> 520*404b540aSrobert // This keeps isalnum, et al from being propagated as macros. 521*404b540aSrobert #if __linux__ 522*404b540aSrobert #define __NO_CTYPE 1 523*404b540aSrobert #endif 524*404b540aSrobert 525*404b540aSrobert [ now include <ctype.h> ] 526*404b540aSrobert </pre> 527*404b540aSrobert<p> 528*404b540aSrobert Another problem arises if you put a <b>using namespace 529*404b540aSrobert std;</b> declaration at the top, and include <tt><ctype.h></tt>. This will result in 530*404b540aSrobert ambiguities between the definitions in the global namespace 531*404b540aSrobert (<tt><ctype.h></tt>) and the 532*404b540aSrobert definitions in namespace <b>std::</b> 533*404b540aSrobert (<b><cctype></b>). 534*404b540aSrobert </p> 535*404b540aSrobert<p> 536*404b540aSrobert The solution to this problem was posted to the libstdc++-v3 537*404b540aSrobert mailing-list: 538*404b540aSrobert Benjamin Kosnik <tt><<a href="mailto:bkoz@redhat.com">bkoz@redhat.com</a>></tt> writes: 539*404b540aSrobert ‘ 540*404b540aSrobert --enable-cshadow-headers is currently broken. As a result, shadow 541*404b540aSrobert headers are not being searched.... 542*404b540aSrobert ’ 543*404b540aSrobert This is now outdated, but gcc 3.0 still does not have fully 544*404b540aSrobert compliant "shadow headers". 545*404b540aSrobert </p> 546*404b540aSrobert</div> 547*404b540aSrobert<div class="section"> 548*404b540aSrobert<div class="titlepage"><div><h2 class="title" style="clear: both"> 549*404b540aSrobert<a name="sec-stream-state"></a>State of streams</h2></div></div> 550*404b540aSrobert<p> 551*404b540aSrobert At least some older implementations don't have 552*404b540aSrobert <b>std::ios_base</b>, so you should use 553*404b540aSrobert <b>std::ios::badbit</b>, <b>std::ios::failbit</b> 554*404b540aSrobert and <b>std::ios::eofbit</b> and 555*404b540aSrobert <b>std::ios::goodbit</b>. 556*404b540aSrobert </p> 557*404b540aSrobert</div> 558*404b540aSrobert<div class="section"> 559*404b540aSrobert<div class="titlepage"><div><h2 class="title" style="clear: both"> 560*404b540aSrobert<a name="sec-vector-at"></a>vector::at is missing (i.e. gcc 2.95.x)</h2></div></div> 561*404b540aSrobert<p> 562*404b540aSrobert One solution is to add an autoconf-test for this: 563*404b540aSrobert <pre class="programlisting"> 564*404b540aSrobert AC_MSG_CHECKING(for container::at) 565*404b540aSrobert AC_TRY_COMPILE( 566*404b540aSrobert [ 567*404b540aSrobert #include <vector> 568*404b540aSrobert #include <deque> 569*404b540aSrobert #include <string> 570*404b540aSrobert 571*404b540aSrobert using namespace std; 572*404b540aSrobert ], 573*404b540aSrobert [ 574*404b540aSrobert deque<int> test_deque(3); 575*404b540aSrobert test_deque.at(2); 576*404b540aSrobert vector<int> test_vector(2); 577*404b540aSrobert test_vector.at(1); 578*404b540aSrobert string test_string("test_string"); 579*404b540aSrobert test_string.at(3); 580*404b540aSrobert ], 581*404b540aSrobert [AC_MSG_RESULT(yes) 582*404b540aSrobert AC_DEFINE(HAVE_CONTAINER_AT)], 583*404b540aSrobert [AC_MSG_RESULT(no)]) 584*404b540aSrobert </pre> 585*404b540aSrobert If you are using other (non-GNU) compilers it might be a good idea 586*404b540aSrobert to check for <b>string::at</b> separately. 587*404b540aSrobert</div> 588*404b540aSrobert<div class="section"> 589*404b540aSrobert<div class="titlepage"><div><h2 class="title" style="clear: both"> 590*404b540aSrobert<a name="sec-eof"></a>Using std::char_traits<char>::eof()</h2></div></div> 591*404b540aSrobert<p> 592*404b540aSrobert <pre class="programlisting"> 593*404b540aSrobert #ifdef HAVE_CHAR_TRAITS 594*404b540aSrobert #define CPP_EOF std::char_traits<char>::eof() 595*404b540aSrobert #else 596*404b540aSrobert #define CPP_EOF EOF 597*404b540aSrobert #endif 598*404b540aSrobert </pre> 599*404b540aSrobert</div> 600*404b540aSrobert<div class="section"> 601*404b540aSrobert<div class="titlepage"><div><h2 class="title" style="clear: both"> 602*404b540aSrobert<a name="sec-string-clear"></a>Using string::clear()/string::erase()</h2></div></div> 603*404b540aSrobert<p> 604*404b540aSrobert There are two functions for deleting the contents of a string: 605*404b540aSrobert <b>clear</b> and <b>erase</b> (the latter 606*404b540aSrobert returns the string). 607*404b540aSrobert <pre class="programlisting"> 608*404b540aSrobert void 609*404b540aSrobert clear() { _M_mutate(0, this->size(), 0); } 610*404b540aSrobert </pre> 611*404b540aSrobert <pre class="programlisting"> 612*404b540aSrobert basic_string& 613*404b540aSrobert erase(size_type __pos = 0, size_type __n = npos) 614*404b540aSrobert { 615*404b540aSrobert return this->replace(_M_check(__pos), _M_fold(__pos, __n), 616*404b540aSrobert _M_data(), _M_data()); 617*404b540aSrobert } 618*404b540aSrobert </pre> 619*404b540aSrobert The implementation of <b>erase</b> seems to be more 620*404b540aSrobert complicated (from libstdc++-v3), but <b>clear</b> is not 621*404b540aSrobert implemented in gcc 2.95.x's libstdc++, so you should use 622*404b540aSrobert <b>erase</b> (which is probably faster than 623*404b540aSrobert <b>operator=(charT*)</b>). 624*404b540aSrobert</div> 625*404b540aSrobert<div class="section"> 626*404b540aSrobert<div class="titlepage"><div><h2 class="title" style="clear: both"> 627*404b540aSrobert<a name="sec-scan-form"></a>GNU Extensions ostream::form and istream::scan</h2></div></div> 628*404b540aSrobert<p> 629*404b540aSrobert These are not supported any more - use 630*404b540aSrobert <a href="#sec-stringstream" title="Using stringstreams"> 631*404b540aSrobert stringstreams</a> instead. 632*404b540aSrobert </p> 633*404b540aSrobert</div> 634*404b540aSrobert<div class="section"> 635*404b540aSrobert<div class="titlepage"><div><h2 class="title" style="clear: both"> 636*404b540aSrobert<a name="sec-stringstream"></a>Using stringstreams</h2></div></div> 637*404b540aSrobert<p> 638*404b540aSrobert Libstdc++-v3 provides the new 639*404b540aSrobert <b>i/ostringstream</b>-classes, (<tt><sstream></tt>), but for compatibility 640*404b540aSrobert with older implementations you still have to use 641*404b540aSrobert <b>i/ostrstream</b> (<tt><strstream></tt>): 642*404b540aSrobert <pre class="programlisting"> 643*404b540aSrobert #ifdef HAVE_SSTREAM 644*404b540aSrobert #include <sstream> 645*404b540aSrobert #else 646*404b540aSrobert #include <strstream> 647*404b540aSrobert #endif 648*404b540aSrobert </pre> 649*404b540aSrobert <div class="itemizedlist"><ul type="disc"> 650*404b540aSrobert<li><p> <b>strstream</b> is considered to be 651*404b540aSrobert deprecated 652*404b540aSrobert </p></li> 653*404b540aSrobert<li><p> <b>strstream</b> is limited to 654*404b540aSrobert <b>char</b> 655*404b540aSrobert </p></li> 656*404b540aSrobert<li><p> with <b>ostringstream</b> you don't 657*404b540aSrobert have to take care of terminating the string or freeing its 658*404b540aSrobert memory 659*404b540aSrobert </p></li> 660*404b540aSrobert<li><p> <b>istringstream</b> can be re-filled 661*404b540aSrobert (clear(); str(input);) 662*404b540aSrobert </p></li> 663*404b540aSrobert</ul></div> 664*404b540aSrobert<p> 665*404b540aSrobert You can then use output-stringstreams like this: 666*404b540aSrobert <pre class="programlisting"> 667*404b540aSrobert #ifdef HAVE_SSTREAM 668*404b540aSrobert std::ostringstream oss; 669*404b540aSrobert #else 670*404b540aSrobert std::ostrstream oss; 671*404b540aSrobert #endif 672*404b540aSrobert oss << "Name=" << m_name << ", number=" << m_number << std::endl; 673*404b540aSrobert ... 674*404b540aSrobert #ifndef HAVE_SSTREAM 675*404b540aSrobert oss << std::ends; // terminate the char*-string 676*404b540aSrobert #endif 677*404b540aSrobert // str() returns char* for ostrstream and a string for ostringstream 678*404b540aSrobert // this also causes ostrstream to think that the buffer's memory 679*404b540aSrobert // is yours 680*404b540aSrobert m_label.set_text(oss.str()); 681*404b540aSrobert #ifndef HAVE_SSTREAM 682*404b540aSrobert // let the ostrstream take care of freeing the memory 683*404b540aSrobert oss.freeze(false); 684*404b540aSrobert #endif 685*404b540aSrobert </pre> 686*404b540aSrobert<p> 687*404b540aSrobert Input-stringstreams can be used similarly: 688*404b540aSrobert <pre class="programlisting"> 689*404b540aSrobert std::string input; 690*404b540aSrobert ... 691*404b540aSrobert #ifdef HAVE_SSTREAM 692*404b540aSrobert std::istringstream iss(input); 693*404b540aSrobert #else 694*404b540aSrobert std::istrstream iss(input.c_str()); 695*404b540aSrobert #endif 696*404b540aSrobert int i; 697*404b540aSrobert iss >> i; 698*404b540aSrobert </pre> 699*404b540aSrobert One (the only?) restriction is that an istrstream cannot be re-filled: 700*404b540aSrobert <pre class="programlisting"> 701*404b540aSrobert std::istringstream iss(numerator); 702*404b540aSrobert iss >> m_num; 703*404b540aSrobert // this is not possible with istrstream 704*404b540aSrobert iss.clear(); 705*404b540aSrobert iss.str(denominator); 706*404b540aSrobert iss >> m_den; 707*404b540aSrobert </pre> 708*404b540aSrobert If you don't care about speed, you can put these conversions in 709*404b540aSrobert a template-function: 710*404b540aSrobert <pre class="programlisting"> 711*404b540aSrobert template <class X> 712*404b540aSrobert void fromString(const string& input, X& any) 713*404b540aSrobert { 714*404b540aSrobert #ifdef HAVE_SSTREAM 715*404b540aSrobert std::istringstream iss(input); 716*404b540aSrobert #else 717*404b540aSrobert std::istrstream iss(input.c_str()); 718*404b540aSrobert #endif 719*404b540aSrobert X temp; 720*404b540aSrobert iss >> temp; 721*404b540aSrobert if (iss.fail()) 722*404b540aSrobert throw runtime_error(..) 723*404b540aSrobert any = temp; 724*404b540aSrobert } 725*404b540aSrobert </pre> 726*404b540aSrobert Another example of using stringstreams is in <a href="../21_strings/howto.html" target="_top">this howto</a>. 727*404b540aSrobert<p> 728*404b540aSrobert I have read the Josuttis book on Standard C++, so some information 729*404b540aSrobert comes from there. Additionally, there is information in 730*404b540aSrobert "info iostream", which covers the old implementation that gcc 2.95.x 731*404b540aSrobert uses. 732*404b540aSrobert </p> 733*404b540aSrobert</div> 734*404b540aSrobert<div class="section"> 735*404b540aSrobert<div class="titlepage"><div><h2 class="title" style="clear: both"> 736*404b540aSrobert<a name="sec-about"></a>About...</h2></div></div> 737*404b540aSrobert<p> 738*404b540aSrobert Please send any experience, additions, corrections or questions to 739*404b540aSrobert <a href="mailto:fnatter@gmx.net" target="_top">fnatter@gmx.net</a> or for 740*404b540aSrobert discussion to the libstdc++-v3-mailing-list. 741*404b540aSrobert </p> 742*404b540aSrobert</div> 743*404b540aSrobert</div></body> 744*404b540aSrobert</html> 745