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