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