diff options
| author | pme <pme@138bc75d-0d04-0410-961f-82ee72b054a4> | 2000-12-10 04:04:56 +0000 |
|---|---|---|
| committer | pme <pme@138bc75d-0d04-0410-961f-82ee72b054a4> | 2000-12-10 04:04:56 +0000 |
| commit | 0d50e69a939bc73845dec8af0c81dee426d15632 (patch) | |
| tree | bdeb62de7e9c37c0ef121bc087f714c44d7e6667 /libstdc++-v3/docs/html/17_intro/porting-howto.html | |
| parent | aee9d5bbf76f22f11c7db2ad238ff4d5cd99df58 (diff) | |
| download | ppe42-gcc-0d50e69a939bc73845dec8af0c81dee426d15632.tar.gz ppe42-gcc-0d50e69a939bc73845dec8af0c81dee426d15632.zip | |
2000-12-09 Phil Edwards <pme@sources.redhat.com>
Move the HTML-containing subdirs from 'docs' to 'docs/html'.
* README: Update the locations of instructions.
* docs/doxygen/run_doxygen: New file, stub.
* docs/Makefile: Moved...
* docs/configopts.html: Likewise.
* docs/documentation.html: Likewise.
* docs/install.html: Likewise.
* docs/lib3styles.css: Likewise.
* docs/17_intro/BADNAMES: Likewise.
* docs/17_intro/BUGS: Likewise.
* docs/17_intro/C++STYLE: Likewise.
* docs/17_intro/CHECKLIST: Likewise.
* docs/17_intro/COPYING: Likewise.
* docs/17_intro/DESIGN: Likewise.
* docs/17_intro/HEADER_POLICY: Likewise.
* docs/17_intro/PROBLEMS: Likewise.
* docs/17_intro/RELEASE-NOTES: Likewise.
* docs/17_intro/TODO: Likewise.
* docs/17_intro/contribute.html: Likewise.
* docs/17_intro/headers_cc.txt: Likewise.
* docs/17_intro/howto.html: Likewise.
* docs/17_intro/libstdc++-assign.txt: Likewise.
* docs/17_intro/organization: Likewise.
* docs/17_intro/porting-howto.html: Likewise.
* docs/18_support/howto.html: Likewise.
* docs/19_diagnostics/howto.html: Likewise.
* docs/20_util/howto.html: Likewise.
* docs/21_strings/gotw29a.txt: Likewise.
* docs/21_strings/howto.html: Likewise.
* docs/21_strings/stringtok_h.txt: Likewise.
* docs/21_strings/stringtok_std_h.txt: Likewise.
* docs/22_locale/codecvt.html: Likewise.
* docs/22_locale/ctype.html: Likewise.
* docs/22_locale/howto.html: Likewise.
* docs/22_locale/locale.html: Likewise.
* docs/23_containers/howto.html: Likewise.
* docs/23_containers/wrappers_h.txt: Likewise.
* docs/24_iterators/howto.html: Likewise.
* docs/25_algorithms/howto.html: Likewise.
* docs/26_numerics/howto.html: Likewise.
* docs/27_io/howto.html: Likewise.
* docs/27_io/iostreams_hierarchy.pdf: Likewise.
* docs/ext/howto.html: Likewise.
* docs/faq/index.html: Likewise.
* docs/faq/index.txt: Likewise.
* docs/html/Makefile: ...to here.
* docs/html/configopts.html: Likewise.
* docs/html/documentation.html: Likewise.
* docs/html/install.html: Likewise.
* docs/html/lib3styles.css: Likewise.
* docs/html/17_intro/BADNAMES: Likewise.
* docs/html/17_intro/BUGS: Likewise.
* docs/html/17_intro/C++STYLE: Likewise.
* docs/html/17_intro/CHECKLIST: Likewise.
* docs/html/17_intro/COPYING: Likewise.
* docs/html/17_intro/DESIGN: Likewise.
* docs/html/17_intro/HEADER_POLICY: Likewise.
* docs/html/17_intro/PROBLEMS: Likewise.
* docs/html/17_intro/RELEASE-NOTES: Likewise.
* docs/html/17_intro/TODO: Likewise.
* docs/html/17_intro/contribute.html: Likewise.
* docs/html/17_intro/headers_cc.txt: Likewise.
* docs/html/17_intro/howto.html: Likewise.
* docs/html/17_intro/libstdc++-assign.txt: Likewise.
* docs/html/17_intro/organization: Likewise.
* docs/html/17_intro/porting-howto.html: Likewise.
* docs/html/18_support/howto.html: Likewise.
* docs/html/19_diagnostics/howto.html: Likewise.
* docs/html/20_util/howto.html: Likewise.
* docs/html/21_strings/gotw29a.txt: Likewise.
* docs/html/21_strings/howto.html: Likewise.
* docs/html/21_strings/stringtok_h.txt: Likewise.
* docs/html/21_strings/stringtok_std_h.txt: Likewise.
* docs/html/22_locale/codecvt.html: Likewise.
* docs/html/22_locale/ctype.html: Likewise.
* docs/html/22_locale/howto.html: Likewise.
* docs/html/22_locale/locale.html: Likewise.
* docs/html/23_containers/howto.html: Likewise.
* docs/html/23_containers/wrappers_h.txt: Likewise.
* docs/html/24_iterators/howto.html: Likewise.
* docs/html/25_algorithms/howto.html: Likewise.
* docs/html/26_numerics/howto.html: Likewise.
* docs/html/27_io/howto.html: Likewise.
* docs/html/27_io/iostreams_hierarchy.pdf: Likewise.
* docs/html/ext/howto.html: Likewise.
* docs/html/faq/index.html: Likewise.
* docs/html/faq/index.txt: Likewise.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@38166 138bc75d-0d04-0410-961f-82ee72b054a4
Diffstat (limited to 'libstdc++-v3/docs/html/17_intro/porting-howto.html')
| -rw-r--r-- | libstdc++-v3/docs/html/17_intro/porting-howto.html | 726 |
1 files changed, 726 insertions, 0 deletions
diff --git a/libstdc++-v3/docs/html/17_intro/porting-howto.html b/libstdc++-v3/docs/html/17_intro/porting-howto.html new file mode 100644 index 00000000000..54290b328c2 --- /dev/null +++ b/libstdc++-v3/docs/html/17_intro/porting-howto.html @@ -0,0 +1,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> |
