mirror of
git://gcc.gnu.org/git/gcc.git
synced 2024-12-26 04:18:58 +08:00
c5504edb75
* ChangeLog, docs/doxygen/maint.cfg.in, docs/doxygen/user.cfg.in, docs/doxygen/doxygroups.cc, docs/doxygen/Intro.3, docs/html/17_intro/BUGS, docs/html/17_intro/C++STYLE, docs/html/17_intro/CHECKLIST, docs/html/17_intro/DESIGN, docs/html/17_intro/howto.html, docs/html/17_intro/porting.html, docs/html/17_intro/porting.texi, docs/html/18_support/howto.html, docs/html/19_diagnostics/howto.html, docs/html/20_util/howto.html, docs/html/21_strings/howto.html, docs/html/23_containers/howto.html, docs/html/26_numerics/howto.html, docs/html/27_io/howto.html, docs/html/27_io/binary_iostreams_kuehl.txt, docs/html/ext/sgiexts.html, docs/html/faq/index.html, docs/html/faq/index.txt, testsuite/24_iterators/iterator.cc, include/bits/basic_file.h, include/bits/locale_facets.h, include/bits/locale_facets.tcc, include/bits/std_sstream.h, include/ext/ropeimpl.h, include/ext/stl_rope.h, libsupc++/tinfo.cc, libsupc++/cxxabi.h, libsupc++/typeinfo, libsupc++/eh_throw.cc, acinclude.m4, aclocal.m4, configure, configure.target, ChangeLog-2000: Fix spelling errors. From-SVN: r47291
338 lines
14 KiB
HTML
338 lines
14 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
<meta name="AUTHOR" content="pme@gcc.gnu.org (Phil Edwards)">
|
|
<meta name="KEYWORDS" content="HOWTO, libstdc++, GCC, g++, libg++, STL">
|
|
<meta name="DESCRIPTION" content="HOWTO for the libstdc++ chapter 21.">
|
|
<meta name="GENERATOR" content="vi and eight fingers">
|
|
<title>libstdc++-v3 HOWTO: Chapter 21</title>
|
|
<link rel="StyleSheet" href="../lib3styles.css">
|
|
</head>
|
|
<body>
|
|
|
|
<h1 class="centered"><a name="top">Chapter 21: Strings</a></h1>
|
|
|
|
<p>Chapter 21 deals with the C++ strings library (a welcome relief).
|
|
</p>
|
|
|
|
|
|
<!-- ####################################################### -->
|
|
<hr>
|
|
<h1>Contents</h1>
|
|
<ul>
|
|
<li><a href="#1">MFC's CString</a>
|
|
<li><a href="#2">A case-insensitive string class</a>
|
|
<li><a href="#3">Breaking a C++ string into tokens</a>
|
|
<li><a href="#4">Simple transformations</a>
|
|
</ul>
|
|
|
|
<hr>
|
|
|
|
<!-- ####################################################### -->
|
|
|
|
<h2><a name="1">MFC's CString</a></h2>
|
|
<p>A common lament seen in various newsgroups deals with the Standard
|
|
string class as opposed to the Microsoft Foundation Class called
|
|
CString. Often programmers realize that a standard portable
|
|
answer is better than a proprietary nonportable one, but in porting
|
|
their application from a Win32 platform, they discover that they
|
|
are relying on special functions offered by the CString class.
|
|
</p>
|
|
<p>Things are not as bad as they seem. In
|
|
<a href="http://gcc.gnu.org/ml/gcc/1999-04n/msg00236.html">this
|
|
message</a>, Joe Buck points out a few very important things:
|
|
<ul>
|
|
<li>The Standard <code>string</code> supports all the operations
|
|
that CString does, with three exceptions.
|
|
<li>Two of those exceptions (whitespace trimming and case
|
|
conversion) are trivial to implement. In fact, we do so
|
|
on this page.
|
|
<li>The third is <code>CString::Format</code>, which allows formatting
|
|
in the style of <code>sprintf</code>. This deserves some mention:
|
|
</ul>
|
|
</p>
|
|
<a name="1.1internal"> <!-- Coming from Chapter 27 -->
|
|
<p>The old libg++ library had a function called form(), which did much
|
|
the same thing. But for a Standard solution, you should use the
|
|
stringstream classes. These are the bridge between the iostream
|
|
hierarchy and the string class, and they operate with regular
|
|
streams seamlessly because they inherit from the iostream
|
|
hierarchy. An quick example:
|
|
<pre>
|
|
#include <iostream>
|
|
#include <string>
|
|
#include <sstream>
|
|
|
|
string f (string& incoming) // incoming is "foo N"
|
|
{
|
|
istringstream incoming_stream(incoming);
|
|
string the_word;
|
|
int the_number;
|
|
|
|
incoming_stream >> the_word // extract "foo"
|
|
>> the_number; // extract N
|
|
|
|
ostringstream output_stream;
|
|
output_stream << "The word was " << the_word
|
|
<< " and 3*N was " << (3*the_number);
|
|
|
|
return output_stream.str();
|
|
} </pre>
|
|
</p></a>
|
|
<p>A serious problem with CString is a design bug in its memory
|
|
allocation. Specifically, quoting from that same message:
|
|
<pre>
|
|
CString suffers from a common programming error that results in
|
|
poor performance. Consider the following code:
|
|
|
|
CString n_copies_of (const CString& foo, unsigned n)
|
|
{
|
|
CString tmp;
|
|
for (unsigned i = 0; i < n; i++)
|
|
tmp += foo;
|
|
return tmp;
|
|
}
|
|
|
|
This function is O(n^2), not O(n). The reason is that each +=
|
|
causes a reallocation and copy of the existing string. Microsoft
|
|
applications are full of this kind of thing (quadratic performance
|
|
on tasks that can be done in linear time) -- on the other hand,
|
|
we should be thankful, as it's created such a big market for high-end
|
|
ix86 hardware. :-)
|
|
|
|
If you replace CString with string in the above function, the
|
|
performance is O(n).
|
|
</pre>
|
|
</p>
|
|
<p>Joe Buck also pointed out some other things to keep in mind when
|
|
comparing CString and the Standard string class:
|
|
<ul>
|
|
<li>CString permits access to its internal representation; coders
|
|
who exploited that may have problems moving to <code>string</code>.
|
|
<li>Microsoft ships the source to CString (in the files
|
|
MFC\SRC\Str{core,ex}.cpp), so you could fix the allocation
|
|
bug and rebuild your MFC libraries.
|
|
<em><B>Note:</B> It looks like the the CString shipped with
|
|
VC++6.0 has fixed this, although it may in fact have been one
|
|
of the VC++ SPs that did it.</em>
|
|
<li><code>string</code> operations like this have O(n) complexity
|
|
<em>if the implementors do it correctly</em>. The libstdc++
|
|
implementors did it correctly. Other vendors might not.
|
|
<li>While parts of the SGI STL are used in libstdc++-v3, their
|
|
string class is not. The SGI <code>string</code> is essentially
|
|
<code>vector<char></code> and does not do any reference
|
|
counting like libstdc++-v3's does. (It is O(n), though.)
|
|
So if you're thinking about SGI's string or rope classes,
|
|
you're now looking at four possibilities: CString, the
|
|
libstdc++ string, the SGI string, and the SGI rope, and this
|
|
is all before any allocator or traits customizations! (More
|
|
choices than you can shake a stick at -- want fries with that?)
|
|
</ul>
|
|
</p>
|
|
<p>Return <a href="#top">to top of page</a> or
|
|
<a href="../faq/index.html">to the FAQ</a>.
|
|
</p>
|
|
|
|
<hr>
|
|
<h2><a name="2">A case-insensitive string class</a></h2>
|
|
<p>The well-known-and-if-it-isn't-well-known-it-ought-to-be
|
|
<a href="http://www.peerdirect.com/resources/">Guru of the Week</a>
|
|
discussions held on Usenet covered this topic in January of 1998.
|
|
Briefly, the challenge was, "write a 'ci_string' class which
|
|
is identical to the standard 'string' class, but is
|
|
case-insensitive in the same way as the (common but nonstandard)
|
|
C function stricmp():"
|
|
<pre>
|
|
ci_string s( "AbCdE" );
|
|
|
|
// case insensitive
|
|
assert( s == "abcde" );
|
|
assert( s == "ABCDE" );
|
|
|
|
// still case-preserving, of course
|
|
assert( strcmp( s.c_str(), "AbCdE" ) == 0 );
|
|
assert( strcmp( s.c_str(), "abcde" ) != 0 ); </pre>
|
|
</p>
|
|
|
|
<p>The solution is surprisingly easy. The original answer pages
|
|
on the GotW website were removed into cold storage, in
|
|
preparation for
|
|
<a href="http://cseng.aw.com/bookpage.taf?ISBN=0-201-61562-2">a
|
|
published book of GotW notes</a>. Before being
|
|
put on the web, of course, it was posted on Usenet, and that
|
|
posting containing the answer is <a href="gotw29a.txt">available
|
|
here</a>.
|
|
</p>
|
|
<p>See? Told you it was easy!</p>
|
|
<p><strong>Added June 2000:</strong> The May issue of <u>C++ Report</u>
|
|
contains
|
|
a fascinating article by Matt Austern (yes, <em>the</em> Matt Austern)
|
|
on why case-insensitive comparisons are not as easy as they seem,
|
|
and why creating a class is the <em>wrong</em> way to go about it in
|
|
production code. (The GotW answer mentions one of the principle
|
|
difficulties; his article mentions more.)
|
|
</p>
|
|
<p>Basically, this is "easy" only if you ignore some things,
|
|
things which may be too important to your program to ignore. (I chose
|
|
to ignore them when originally writing this entry, and am surprised
|
|
that nobody ever called me on it...) The GotW question and answer
|
|
remain useful instructional tools, however.
|
|
</p>
|
|
<p><strong>Added September 2000:</strong> James Kanze provided a link to a
|
|
<a href="http://www.unicode.org/unicode/reports/tr21/">Unicode
|
|
Technical Report discussing case handling</a>, which provides some
|
|
very good information.
|
|
</p>
|
|
<p>Return <a href="#top">to top of page</a> or
|
|
<a href="../faq/index.html">to the FAQ</a>.
|
|
</p>
|
|
|
|
<hr>
|
|
<h2><a name="3">Breaking a C++ string into tokens</a></h2>
|
|
<p>The Standard C (and C++) function <code>strtok()</code> leaves a lot to
|
|
be desired in terms of user-friendliness. It's unintuitive, it
|
|
destroys the character string on which it operates, and it requires
|
|
you to handle all the memory problems. But it does let the client
|
|
code decide what to use to break the string into pieces; it allows
|
|
you to choose the "whitespace," so to speak.
|
|
</p>
|
|
<p>A C++ implementation lets us keep the good things and fix those
|
|
annoyances. The implementation here is more intuitive (you only
|
|
call it once, not in a loop with varying argument), it does not
|
|
affect the original string at all, and all the memory allocation
|
|
is handled for you.
|
|
</p>
|
|
<p>It's called stringtok, and it's a template function. It's given
|
|
<a href="stringtok_h.txt">in this file</a> in a less-portable form than
|
|
it could be, to keep this example simple (for example, see the
|
|
comments on what kind of string it will accept). The author uses
|
|
a more general (but less readable) form of it for parsing command
|
|
strings and the like. If you compiled and ran this code using it:
|
|
<pre>
|
|
std::list<string> ls;
|
|
stringtok (ls, " this \t is\t\n a test ");
|
|
for (std::list<string>const_iterator i = ls.begin();
|
|
i != ls.end(); ++i)
|
|
{
|
|
std::cerr << ':' << (*i) << ":\n";
|
|
}</pre>
|
|
You would see this as output:
|
|
<pre>
|
|
:this:
|
|
:is:
|
|
:a:
|
|
:test:</pre>
|
|
with all the whitespace removed. The original <code>s</code> is still
|
|
available for use, <code>ls</code> will clean up after itself, and
|
|
<code>ls.size()</code> will return how many tokens there were.
|
|
</p>
|
|
<p>As always, there is a price paid here, in that stringtok is not
|
|
as fast as strtok. The other benefits usually outweight that, however.
|
|
<a href="stringtok_std_h.txt">Another version of stringtok is given
|
|
here</a>, suggested by Chris King and tweaked by Petr Prikryl,
|
|
and this one uses the
|
|
transformation functions mentioned below. If you are comfortable
|
|
with reading the new function names, this version is recommended
|
|
as an example.
|
|
</p>
|
|
<p><strong>Added February 2001:</strong> Mark Wilden pointed out that the
|
|
standard <code>std::getline()</code> function can be used with standard
|
|
<a href="../27_io/howto.html">istringstreams</a> to perform
|
|
tokenizing as well. Build an istringstream from the input text,
|
|
and then use std::getline with varying delimiters (the three-argument
|
|
signature) to extract tokens into a string.
|
|
</p>
|
|
<p>Return <a href="#top">to top of page</a> or
|
|
<a href="../faq/index.html">to the FAQ</a>.
|
|
</p>
|
|
|
|
<hr>
|
|
<h2><a name="4">Simple transformations</a></h2>
|
|
<p>Here are Standard, simple, and portable ways to perform common
|
|
transformations on a <code>string</code> instance, such as "convert
|
|
to all upper case." The word transformations is especially
|
|
apt, because the standard template function
|
|
<code>transform<></code> is used.
|
|
</p>
|
|
<p>This code will go through some iterations (no pun). Here's the
|
|
simplistic version usually seen on Usenet:
|
|
<pre>
|
|
#include <string>
|
|
#include <algorithm>
|
|
#include <cctype> // old <ctype.h>
|
|
|
|
std::string s ("Some Kind Of Initial Input Goes Here");
|
|
|
|
// Change everything into upper case
|
|
std::transform (s.begin(), s.end(), s.begin(), toupper);
|
|
|
|
// Change everything into lower case
|
|
std::transform (s.begin(), s.end(), s.begin(), tolower);
|
|
|
|
// Change everything back into upper case, but store the
|
|
// result in a different string
|
|
std::string capital_s;
|
|
capital_s.reserve(s.size());
|
|
std::transform (s.begin(), s.end(), capital_s.begin(), tolower); </pre>
|
|
<span class="larger"><strong>Note</strong></span> that these calls all
|
|
involve the global C locale through the use of the C functions
|
|
<code>toupper/tolower</code>. This is absolutely guaranteed to work --
|
|
but <em>only</em> if the string contains <em>only</em> characters
|
|
from the basic source character set, and there are <em>only</em>
|
|
96 of those. Which means that not even all English text can be
|
|
represented (certain British spellings, proper names, and so forth).
|
|
So, if all your input forevermore consists of only those 96
|
|
characters (hahahahahaha), then you're done.
|
|
</p>
|
|
<p>At minimum, you can write short wrappers like
|
|
<pre>
|
|
char toLower (char c)
|
|
{
|
|
return tolower(static_cast<unsigned char>(c));
|
|
}</pre>
|
|
</p>
|
|
<p>The correct method is to use a facet for a particular locale
|
|
and call its conversion functions. These are discussed more in
|
|
Chapter 22; the specific part is
|
|
<a href="../22_locale/howto.html#5">here</a>, which shows the
|
|
final version of this code. (Thanks to James Kanze for assistance
|
|
and suggestions on all of this.)
|
|
</p>
|
|
<p>Another common operation is trimming off excess whitespace. Much
|
|
like transformations, this task is trivial with the use of string's
|
|
<code>find</code> family. These examples are broken into multiple
|
|
statements for readability:
|
|
<pre>
|
|
std::string str (" \t blah blah blah \n ");
|
|
|
|
// trim leading whitespace
|
|
string::size_type notwhite = str.find_first_not_of(" \t\n");
|
|
str.erase(0,notwhite);
|
|
|
|
// trim trailing whitespace
|
|
notwhite = str.find_last_not_of(" \t\n");
|
|
str.erase(notwhite+1); </pre>
|
|
Obviously, the calls to <code>find</code> could be inserted directly
|
|
into the calls to <code>erase</code>, in case your compiler does not
|
|
optimize named temporaries out of existence.
|
|
</p>
|
|
<p>Return <a href="#top">to top of page</a> or
|
|
<a href="../faq/index.html">to the FAQ</a>.
|
|
</p>
|
|
|
|
|
|
|
|
<!-- ####################################################### -->
|
|
|
|
<hr>
|
|
<p class="fineprint"><em>
|
|
See <a href="../17_intro/license.html">license.html</a> for copying conditions.
|
|
Comments and suggestions are welcome, and may be sent to
|
|
<a href="mailto:libstdc++@gcc.gnu.org">the libstdc++ mailing list</a>.
|
|
</em></p>
|
|
|
|
|
|
</body>
|
|
</html>
|