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<p> 187 Because there are many compilers which still use an implementation 188 that does not have the standard C++-library in namespace 189 <b>std::</b>, some care is required to support these as 190 well. 191 </p> 192<p> 193 Namespace back-portability-issues are generally not a problem with 194 g++, because versions of g++ that do not have libstdc++ in 195 <b>std::</b> use <b>-fno-honor-std</b> 196 (ignore <b>std::</b>, <b>:: = std::</b>) by 197 default. That is, the responsibility for enabling or disabling 198 <b>std::</b> is on the user; the maintainer does not have 199 to care about it. This probably applies to some other compilers as 200 well. 201 </p> 202<p> 203 The following sections list some possible solutions to support compilers 204 that cannot ignore std::. 205 </p> 206<div class="section"> 207<div class="titlepage"><div><h3 class="title"> 208<a name="sec-gtkmm-hack"></a>Using <span class="emphasis"><i>namespace 209 composition</i></span> if the project uses a separate 210 namespace</h3></div></div> 211<p> 212 <a href="http://gtkmm.sourceforge.net" target="_top">Gtk--</a> defines 213 most of its classes in namespace Gtk::. Thus, it was possible to 214 adapt Gtk-- to namespace std:: by using a C++-feature called 215 <span class="emphasis"><i>namespace composition</i></span>. This is what happens if 216 you put a <span class="emphasis"><i>using</i></span>-declaration into a 217 namespace-definition: the imported symbol(s) gets imported into the 218 currently active namespace(s). For example: 219 <pre class="programlisting"> 220 namespace Gtk { 221 using std::string; 222 class Window { ... } 223 } 224 </pre> 225 In this example, <b>std::string</b> gets imported into 226 namespace Gtk::. The result is that you don't have to use 227 <b>std::string</b> in this header, but still 228 <b>std::string</b> does not get imported into 229 the global namespace (::) unless the user does 230 <b>using namespace Gtk;</b> (which is not recommended 231 practice for Gtk--, so it is not a problem). Additionally, the 232 <b>using</b>-declarations are wrapped in macros that 233 are set based on autoconf-tests to either "" or i.e. <b>using 234 std::string;</b> (depending on whether the system has 235 libstdc++ in <b>std::</b> or not). (ideas from 236 <tt><<a href="mailto:llewelly@dbritsch.dsl.xmission.com">llewelly@dbritsch.dsl.xmission.com</a>></tt>, Karl Nelson 237 <tt><<a href="mailto:kenelson@ece.ucdavis.edu">kenelson@ece.ucdavis.edu</a>></tt>) 238 </p> 239</div> 240<div class="section"> 241<div class="titlepage"><div><h3 class="title"> 242<a name="sec-emptyns"></a>Defining an empty namespace std</h3></div></div> 243<p> 244 By defining an (empty) namespace <b>std::</b> before 245 using it, you avoid getting errors on systems where no part of the 246 library is in namespace std: 247 <pre class="programlisting"> 248 namespace std { } 249 using namespace std; 250 </pre> 251 </p> 252</div> 253<div class="section"> 254<div class="titlepage"><div><h3 class="title"> 255<a name="sec-avoidfqn"></a>Avoid to use fully qualified names 256 (i.e. std::string)</h3></div></div> 257<p> 258 If some compilers complain about <b>using 259 std::string;</b>, and if the "hack" for gtk-- mentioned above 260 does not work, then I see two solutions: 261 262 <div class="itemizedlist"><ul type="disc"> 263<li><p> 264 Define <b>std::</b> as a macro if the compiler 265 doesn't know about <b>std::</b>. 266 <pre class="programlisting"> 267 #ifdef OLD_COMPILER 268 #define std 269 #endif 270 </pre> 271 (thanks to Juergen Heinzl who posted this solution on 272 gnu.gcc.help) 273 </p></li> 274<li><p> 275 Define a macro NS_STD, which is defined to 276 either "" or "std" 277 based on an autoconf-test. Then you should be able to use 278 <b>NS_STD::string</b>, which will evaluate to 279 <b>::string</b> ("string in the global namespace") on 280 systems that do not put string in std::. (This is untested) 281 </p></li> 282</ul></div> 283 284 </p> 285</div> 286<div class="section"> 287<div class="titlepage"><div><h3 class="title"> 288<a name="sec-osprojects"></a>How some open-source-projects deal 289 with this</h3></div></div> 290<p> 291 This information was gathered around May 2000. It may not be correct 292 by the time you read this. 293 </p> 294<div class="table"> 295<p><b>Table 1. Namespace std:: in Open-Source programs</b></p> 296<table summary="Namespace std:: in Open-Source programs" border="1"> 297<colgroup> 298<col> 299<col> 300</colgroup> 301<tbody> 302<tr> 303<td><a href="http://www.clanlib.org" target="_top">clanlib</a></td> 304<td>usual</td> 305</tr> 306<tr> 307<td><a href="http://pingus.seul.org" target="_top">pingus</a></td> 308<td>usual</td> 309</tr> 310<tr> 311<td><a href="http://www.mozilla.org" target="_top">mozilla</a></td> 312<td>usual</td> 313</tr> 314<tr> 315<td><a href="http://www.mnemonic.org" target="_top">mnemonic</a></td> 316<td>none</td> 317</tr> 318<tr> 319<td><a href="http://libsigc.sourceforge.net" target="_top"> 320 libsigc++</a></td> 321<td>conservative-impl</td> 322</tr> 323</tbody> 324</table> 325</div> 326<div class="table"> 327<p><b>Table 2. Notations for categories</b></p> 328<table summary="Notations for categories" border="1"> 329<colgroup> 330<col> 331<col> 332</colgroup> 333<tbody> 334<tr> 335<td>usual</td> 336<td>mostly fully qualified names and some 337 using-declarations (but not in headers)</td> 338</tr> 339<tr> 340<td>none</td> 341<td>no namespace std at all</td> 342</tr> 343<tr> 344<td>conservative-impl</td> 345<td>wrap all 346 namespace-handling in macros to support compilers without 347 namespace-support (no libstdc++ used in headers)</td> 348</tr> 349</tbody> 350</table> 351</div> 352<p> 353 As you can see, this currently lacks an example of a project 354 which uses libstdc++-symbols in headers in a back-portable way 355 (except for Gtk--: see the <a href="#sec-gtkmm-hack" title="Using namespace 356 composition if the project uses a separate 357 namespace">section on the gtkmm-hack</a>). 358 </p> 359</div> 360</div> 361<div class="section"> 362<div class="titlepage"><div><h2 class="title" style="clear: both"> 363<a name="sec-nocreate"></a>there is no ios::nocreate/ios::noreplace 364 in ISO 14882</h2></div></div> 365<p> 366 I have seen <b>ios::nocreate</b> being used for 367 input-streams, most probably because the author thought it would be 368 more correct to specify nocreate "explicitly". So you can simply 369 leave it out for input-streams. 370 </p> 371<p> 372 For output streams, "nocreate" is probably the default, unless you 373 specify <b>std::ios::trunc</b> ? To be safe, you can open 374 the file for reading, check if it has been opened, and then decide 375 whether you want to create/replace or not. To my knowledge, even 376 older implementations support <b>app</b>, 377 <b>ate</b> and <b>trunc</b> (except for 378 <b>app</b> ?). 379 </p> 380</div> 381<div class="section"> 382<div class="titlepage"><div><h2 class="title" style="clear: both"> 383<a name="sec-stream::attach"></a><b>stream::attach(int 384 fd)</b> is not in the standard any more</h2></div></div> 385<p> 386 Phil Edwards <tt><<a href="mailto:pedwards@disaster.jaj.com">pedwards@disaster.jaj.com</a>></tt> writes: 387 It was considered and rejected. Not all environments use file 388 descriptors. Of those that do, not all of them use integers to represent 389 them. 390 </p> 391<p> 392 When using libstdc++-v3, you can use 393 <div class="funcsynopsis"> 394<pre class="funcsynopsisinfo"> 395 #include <fstream> 396 </pre> 397<p><code><code class="funcdef"> 398 <b class="fsfunc">basic_filebuf<...>::basic_filebuf<...> 399 </b> 400 </code>(<var class="pdparam">file</var>, <var class="pdparam">mode</var>, <var class="pdparam">size</var>);<br>__c_file_type* <var class="pdparam">file</var>;<br>ios_base::open_mode <var class="pdparam">mode</var>;<br>int <var class="pdparam">size</var>;</code></p> 401</div> 402 but the the signature of this constructor has changed often, and 403 it might change again. For the current state of this, check 404 <a href="../ext/howto.html" target="_top">the howto for extensions</a>. 405 </p> 406<p> 407 For a portable solution (among systems which use 408 filedescriptors), you need to implement a subclass of 409 <b>std::streambuf</b> (or 410 <b>std::basic_streambuf<..></b>) which opens a file 411 given a descriptor, and then pass an instance of this to the 412 stream-constructor. For an example of this, refer to 413 <a href="http://www.josuttis.com/cppcode/fdstream.html" target="_top">fdstream example</a> 414 by Nicolai Josuttis. 415 </p> 416</div> 417<div class="section"> 418<div class="titlepage"><div><h2 class="title" style="clear: both"> 419<a name="sec-headers"></a>The new headers</h2></div></div> 420<p> 421 All new headers can be seen in this <a href="headers_cc.txt" target="_top"> 422 source-code</a>. 423 </p> 424<p> 425 The old C++-headers (iostream.h etc.) are available, but gcc generates 426 a warning that you are using deprecated headers. 427 </p> 428<div class="section"> 429<div class="titlepage"><div><h3 class="title"> 430<a name="sec-cheaders"></a>New headers replacing C-headers</h3></div></div> 431<p> 432 You should not use the C-headers (except for system-level 433 headers) from C++ programs. Instead, you should use a set of 434 headers that are named by prepending 'c' and, as usual, 435 omitting the extension (.h). For example, instead of using 436 <tt><math.h></tt>, you 437 should use <tt><cmath></tt>. In some cases this has 438 the advantage that the C++-header is more standardized than 439 the C-header (i.e. <tt><ctime></tt> (almost) 440 corresponds to either <tt><time.h></tt> or <tt><sys/time.h></tt>). 441 442 The standard specifies that if you include the C-style header 443 (<tt><math.h></tt> in 444 this case), the symbols will be available both in the global 445 namespace and in namespace <b>std::</b> (but 446 libstdc++ does not yet have fully compliant headers) On the 447 other hand, if you include only the new header (i.e. <tt><cmath></tt>), the symbols 448 will only be defined in namespace <b>std::</b> 449 (and macros will be converted to inline-functions). 450 </p> 451<p> 452 For more information on this, and for information on how the 453 GNU C++ implementation might reuse ("shadow") the C 454 library-functions, have a look at <a href="http://www.cantrip.org/cheaders.html" target="_top"> 455 www.cantrip.org</a>. 456 </p> 457</div> 458<div class="section"> 459<div class="titlepage"><div><h3 class="title"> 460<a name="sec-fstream-header"></a> 461 <tt><fstream></tt> does 462 not define <b>std::cout</b>, 463 <b>std::cin</b> etc.</h3></div></div> 464<p> 465 In earlier versions of the standard, 466 <tt><fstream.h></tt>, 467 <tt><ostream.h></tt> 468 and <tt><istream.h></tt> 469 used to define 470 <b>cout</b>, <b>cin</b> and so on. Because 471 of the templatized iostreams in libstdc++-v3, you need to include 472 <tt><iostream></tt> 473 explicitly to define these. 474 </p> 475</div> 476</div> 477<div class="section"> 478<div class="titlepage"><div><h2 class="title" style="clear: both"> 479<a name="sec-iterators"></a>Iterators</h2></div></div> 480<p> 481 The following are not proper uses of iterators, but may be working 482 fixes for existing uses of iterators. 483 <div class="itemizedlist"><ul type="disc"> 484<li><p>you cannot do 485 <b>ostream::operator<<(iterator)</b> to 486 print the address of the iterator => use 487 <b>operator<< &*iterator</b> instead ? 488 </p></li> 489<li><p>you cannot clear an iterator's reference 490 (<b>iterator = 0</b>) => use 491 <b>iterator = iterator_type();</b> ? 492 </p></li> 493<li><p> 494<b>if (iterator)</b> won't work any 495 more => use <b>if (iterator != iterator_type())</b> 496 ?</p></li> 497</ul></div> 498 </p> 499</div> 500<div class="section"> 501<div class="titlepage"><div><h2 class="title" style="clear: both"> 502<a name="sec-macros"></a> 503 Libc-macros (i.e. <b>isspace</b> from 504 <tt><cctype></tt>)</h2></div></div> 505<p> 506 Glibc 2.0.x and 2.1.x define the 507 <tt><ctype.h></tt> 508 -functionality as macros (isspace, isalpha etc.). Libstdc++-v3 509 "shadows" these macros as described in the <a href="#sec-cheaders" title="New headers replacing C-headers">section about 510 c-headers</a>. 511 </p> 512<p> 513 Older implementations of libstdc++ (g++-2 for egcs 1.x and g++-3 514 for gcc 2.95.x), however, keep these functions as macros, and so it 515 is not back-portable to use fully qualified names. For example: 516 <pre class="programlisting"> 517 #include <cctype> 518 int main() { std::isspace('X'); } 519 </pre> 520 will result in something like this (unless using g++-v3): 521 <pre class="programlisting"> 522 std:: (__ctype_b[(int) ( ( 'X' ) )] & (unsigned short int) 523 _ISspace ) ; 524 </pre> 525 </p> 526<p> 527 One solution I can think of is to test for -v3 using 528 autoconf-macros, and define macros for each of the C-functions 529 (maybe that is possible with one "wrapper" macro as well ?). 530 </p> 531<p> 532 Another solution which would fix g++ is to tell the user to modify a 533 header-file so that g++-2 (egcs 1.x) and g++-3 (gcc 2.95.x) define a 534 macro which tells <tt><ctype.h></tt> to define functions 535 instead of macros: 536 <pre class="programlisting"> 537 // This keeps isalnum, et al from being propagated as macros. 538 #if __linux__ 539 #define __NO_CTYPE 1 540 #endif 541 542 [ now include <ctype.h> ] 543 </pre> 544 </p> 545<p> 546 Another problem arises if you put a <b>using namespace 547 std;</b> declaration at the top, and include <tt><ctype.h></tt>. This will result in 548 ambiguities between the definitions in the global namespace 549 (<tt><ctype.h></tt>) and the 550 definitions in namespace <b>std::</b> 551 (<b><cctype></b>). 552 </p> 553<p> 554 The solution to this problem was posted to the libstdc++-v3 555 mailing-list: 556 Benjamin Kosnik <tt><<a href="mailto:bkoz@redhat.com">bkoz@redhat.com</a>></tt> writes: 557 ‘ 558 --enable-cshadow-headers is currently broken. As a result, shadow 559 headers are not being searched.... 560 ’ 561 This is now outdated, but gcc 3.0 still does not have fully 562 compliant "shadow headers". 563 </p> 564</div> 565<div class="section"> 566<div class="titlepage"><div><h2 class="title" style="clear: both"> 567<a name="sec-stream-state"></a>State of streams</h2></div></div> 568<p> 569 At least some older implementations don't have 570 <b>std::ios_base</b>, so you should use 571 <b>std::ios::badbit</b>, <b>std::ios::failbit</b> 572 and <b>std::ios::eofbit</b> and 573 <b>std::ios::goodbit</b>. 574 </p> 575</div> 576<div class="section"> 577<div class="titlepage"><div><h2 class="title" style="clear: both"> 578<a name="sec-vector-at"></a>vector::at is missing (i.e. gcc 2.95.x)</h2></div></div> 579<p> 580 One solution is to add an autoconf-test for this: 581 <pre class="programlisting"> 582 AC_MSG_CHECKING(for container::at) 583 AC_TRY_COMPILE( 584 [ 585 #include <vector> 586 #include <deque> 587 #include <string> 588 589 using namespace std; 590 ], 591 [ 592 deque<int> test_deque(3); 593 test_deque.at(2); 594 vector<int> test_vector(2); 595 test_vector.at(1); 596 string test_string("test_string"); 597 test_string.at(3); 598 ], 599 [AC_MSG_RESULT(yes) 600 AC_DEFINE(HAVE_CONTAINER_AT)], 601 [AC_MSG_RESULT(no)]) 602 </pre> 603 If you are using other (non-GNU) compilers it might be a good idea 604 to check for <b>string::at</b> separately. 605 </p> 606</div> 607<div class="section"> 608<div class="titlepage"><div><h2 class="title" style="clear: both"> 609<a name="sec-eof"></a>Using std::char_traits<char>::eof()</h2></div></div> 610<p> 611 <pre class="programlisting"> 612 #ifdef HAVE_CHAR_TRAITS 613 #define CPP_EOF std::char_traits<char>::eof() 614 #else 615 #define CPP_EOF EOF 616 #endif 617 </pre> 618 </p> 619</div> 620<div class="section"> 621<div class="titlepage"><div><h2 class="title" style="clear: both"> 622<a name="sec-string-clear"></a>Using string::clear()/string::erase()</h2></div></div> 623<p> 624 There are two functions for deleting the contents of a string: 625 <b>clear</b> and <b>erase</b> (the latter 626 returns the string). 627 <pre class="programlisting"> 628 void 629 clear() { _M_mutate(0, this->size(), 0); } 630 </pre> 631 <pre class="programlisting"> 632 basic_string& 633 erase(size_type __pos = 0, size_type __n = npos) 634 { 635 return this->replace(_M_check(__pos), _M_fold(__pos, __n), 636 _M_data(), _M_data()); 637 } 638 </pre> 639 The implementation of <b>erase</b> seems to be more 640 complicated (from libstdc++-v3), but <b>clear</b> is not 641 implemented in gcc 2.95.x's libstdc++, so you should use 642 <b>erase</b> (which is probably faster than 643 <b>operator=(charT*)</b>). 644 </p> 645</div> 646<div class="section"> 647<div class="titlepage"><div><h2 class="title" style="clear: both"> 648<a name="sec-scan-form"></a>GNU Extensions ostream::form and istream::scan</h2></div></div> 649<p> 650 These are not supported any more - use 651 <a href="#sec-stringstream" title="Using stringstreams"> 652 stringstreams</a> instead. 653 </p> 654</div> 655<div class="section"> 656<div class="titlepage"><div><h2 class="title" style="clear: both"> 657<a name="sec-stringstream"></a>Using stringstreams</h2></div></div> 658<p> 659 Libstdc++-v3 provides the new 660 <b>i/ostringstream</b>-classes, (<tt><sstream></tt>), but for compatibility 661 with older implementations you still have to use 662 <b>i/ostrstream</b> (<tt><strstream></tt>): 663 <pre class="programlisting"> 664 #ifdef HAVE_SSTREAM 665 #include <sstream> 666 #else 667 #include <strstream> 668 #endif 669 </pre> 670 <div class="itemizedlist"><ul type="disc"> 671<li><p> <b>strstream</b> is considered to be 672 deprecated 673 </p></li> 674<li><p> <b>strstream</b> is limited to 675 <b>char</b> 676 </p></li> 677<li><p> with <b>ostringstream</b> you don't 678 have to take care of terminating the string or freeing its 679 memory 680 </p></li> 681<li><p> <b>istringstream</b> can be re-filled 682 (clear(); str(input);) 683 </p></li> 684</ul></div> 685 </p> 686<p> 687 You can then use output-stringstreams like this: 688 <pre class="programlisting"> 689 #ifdef HAVE_SSTREAM 690 std::ostringstream oss; 691 #else 692 std::ostrstream oss; 693 #endif 694 oss << "Name=" << m_name << ", number=" << m_number << std::endl; 695 ... 696 #ifndef HAVE_SSTREAM 697 oss << std::ends; // terminate the char*-string 698 #endif 699 // str() returns char* for ostrstream and a string for ostringstream 700 // this also causes ostrstream to think that the buffer's memory 701 // is yours 702 m_label.set_text(oss.str()); 703 #ifndef HAVE_SSTREAM 704 // let the ostrstream take care of freeing the memory 705 oss.freeze(false); 706 #endif 707 </pre> 708 </p> 709<p> 710 Input-stringstreams can be used similarly: 711 <pre class="programlisting"> 712 std::string input; 713 ... 714 #ifdef HAVE_SSTREAM 715 std::istringstream iss(input); 716 #else 717 std::istrstream iss(input.c_str()); 718 #endif 719 int i; 720 iss >> i; 721 </pre> 722 One (the only?) restriction is that an istrstream cannot be re-filled: 723 <pre class="programlisting"> 724 std::istringstream iss(numerator); 725 iss >> m_num; 726 // this is not possible with istrstream 727 iss.clear(); 728 iss.str(denominator); 729 iss >> m_den; 730 </pre> 731 If you don't care about speed, you can put these conversions in 732 a template-function: 733 <pre class="programlisting"> 734 template <class X> 735 void fromString(const string& input, X& any) 736 { 737 #ifdef HAVE_SSTREAM 738 std::istringstream iss(input); 739 #else 740 std::istrstream iss(input.c_str()); 741 #endif 742 X temp; 743 iss >> temp; 744 if (iss.fail()) 745 throw runtime_error(..) 746 any = temp; 747 } 748 </pre> 749 Another example of using stringstreams is in <a href="../21_strings/howto.html" target="_top">this howto</a>. 750 </p> 751<p> 752 I have read the Josuttis book on Standard C++, so some information 753 comes from there. Additionally, there is information in 754 "info iostream", which covers the old implementation that gcc 2.95.x 755 uses. 756 </p> 757</div> 758<div class="section"> 759<div class="titlepage"><div><h2 class="title" style="clear: both"> 760<a name="sec-about"></a>About...</h2></div></div> 761<p> 762 Please send any experience, additions, corrections or questions to 763 <a href="mailto:fnatter@gmx.net" target="_top">fnatter@gmx.net</a> or for 764 discussion to the libstdc++-v3-mailing-list. 765 </p> 766</div> 767</div></body> 768</html> 769