14fee23f9Smrg<?xml version="1.0" encoding="UTF-8" standalone="no"?> 2d79abf08Smrg<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 7. Strings</title><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><meta name="keywords" content="ISO C++, library" /><meta name="keywords" content="ISO C++, runtime, library" /><link rel="home" href="../index.html" title="The GNU C++ Library" /><link rel="up" href="std_contents.html" title="Part II. Standard Contents" /><link rel="prev" href="traits.html" title="Traits" /><link rel="next" href="localization.html" title="Chapter 8. Localization" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 7. 34fee23f9Smrg Strings 44fee23f9Smrg 548fb7bfaSmrg</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="traits.html">Prev</a> </td><th width="60%" align="center">Part II. 648fb7bfaSmrg Standard Contents 748fb7bfaSmrg </th><td width="20%" align="right"> <a accesskey="n" href="localization.html">Next</a></td></tr></table><hr /></div><div class="chapter"><div class="titlepage"><div><div><h2 class="title"><a id="std.strings"></a>Chapter 7. 84fee23f9Smrg Strings 94d5abbe8Smrg <a id="id-1.3.4.5.1.1.1" class="indexterm"></a> 1048fb7bfaSmrg</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="section"><a href="strings.html#std.strings.string">String Classes</a></span></dt><dd><dl><dt><span class="section"><a href="strings.html#strings.string.simple">Simple Transformations</a></span></dt><dt><span class="section"><a href="strings.html#strings.string.case">Case Sensitivity</a></span></dt><dt><span class="section"><a href="strings.html#strings.string.character_types">Arbitrary Character Types</a></span></dt><dt><span class="section"><a href="strings.html#strings.string.token">Tokenizing</a></span></dt><dt><span class="section"><a href="strings.html#strings.string.shrink">Shrink to Fit</a></span></dt><dt><span class="section"><a href="strings.html#strings.string.Cstring">CString (MFC)</a></span></dt></dl></dd></dl></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="std.strings.string"></a>String Classes</h2></div></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="strings.string.simple"></a>Simple Transformations</h3></div></div></div><p> 1148fb7bfaSmrg Here are Standard, simple, and portable ways to perform common 1248fb7bfaSmrg transformations on a <code class="code">string</code> instance, such as 1348fb7bfaSmrg "convert to all upper case." The word transformations 1448fb7bfaSmrg is especially apt, because the standard template function 1548fb7bfaSmrg <code class="code">transform<></code> is used. 1648fb7bfaSmrg </p><p> 1748fb7bfaSmrg This code will go through some iterations. Here's a simple 1848fb7bfaSmrg version: 1948fb7bfaSmrg </p><pre class="programlisting"> 2048fb7bfaSmrg #include <string> 2148fb7bfaSmrg #include <algorithm> 2248fb7bfaSmrg #include <cctype> // old <ctype.h> 2348fb7bfaSmrg 2448fb7bfaSmrg struct ToLower 2548fb7bfaSmrg { 2648fb7bfaSmrg char operator() (char c) const { return std::tolower(c); } 2748fb7bfaSmrg }; 2848fb7bfaSmrg 2948fb7bfaSmrg struct ToUpper 3048fb7bfaSmrg { 3148fb7bfaSmrg char operator() (char c) const { return std::toupper(c); } 3248fb7bfaSmrg }; 3348fb7bfaSmrg 3448fb7bfaSmrg int main() 3548fb7bfaSmrg { 3648fb7bfaSmrg std::string s ("Some Kind Of Initial Input Goes Here"); 3748fb7bfaSmrg 3848fb7bfaSmrg // Change everything into upper case 3948fb7bfaSmrg std::transform (s.begin(), s.end(), s.begin(), ToUpper()); 4048fb7bfaSmrg 4148fb7bfaSmrg // Change everything into lower case 4248fb7bfaSmrg std::transform (s.begin(), s.end(), s.begin(), ToLower()); 4348fb7bfaSmrg 4448fb7bfaSmrg // Change everything back into upper case, but store the 4548fb7bfaSmrg // result in a different string 4648fb7bfaSmrg std::string capital_s; 4748fb7bfaSmrg capital_s.resize(s.size()); 4848fb7bfaSmrg std::transform (s.begin(), s.end(), capital_s.begin(), ToUpper()); 4948fb7bfaSmrg } 5048fb7bfaSmrg </pre><p> 5148fb7bfaSmrg <span class="emphasis"><em>Note</em></span> that these calls all 5248fb7bfaSmrg involve the global C locale through the use of the C functions 5348fb7bfaSmrg <code class="code">toupper/tolower</code>. This is absolutely guaranteed to work -- 5448fb7bfaSmrg but <span class="emphasis"><em>only</em></span> if the string contains <span class="emphasis"><em>only</em></span> characters 5548fb7bfaSmrg from the basic source character set, and there are <span class="emphasis"><em>only</em></span> 5648fb7bfaSmrg 96 of those. Which means that not even all English text can be 5748fb7bfaSmrg represented (certain British spellings, proper names, and so forth). 5848fb7bfaSmrg So, if all your input forevermore consists of only those 96 5948fb7bfaSmrg characters (hahahahahaha), then you're done. 6048fb7bfaSmrg </p><p><span class="emphasis"><em>Note</em></span> that the 6148fb7bfaSmrg <code class="code">ToUpper</code> and <code class="code">ToLower</code> function objects 6248fb7bfaSmrg are needed because <code class="code">toupper</code> and <code class="code">tolower</code> 6348fb7bfaSmrg are overloaded names (declared in <code class="code"><cctype></code> and 6448fb7bfaSmrg <code class="code"><locale></code>) so the template-arguments for 6548fb7bfaSmrg <code class="code">transform<></code> cannot be deduced, as explained in 6648fb7bfaSmrg <a class="link" href="http://gcc.gnu.org/ml/libstdc++/2002-11/msg00180.html" target="_top">this 6748fb7bfaSmrg message</a>. 6848fb7bfaSmrg 6948fb7bfaSmrg At minimum, you can write short wrappers like 7048fb7bfaSmrg </p><pre class="programlisting"> 7148fb7bfaSmrg char toLower (char c) 7248fb7bfaSmrg { 73*a3e9eb18Smrg // std::tolower(c) is undefined if c < 0 so cast to unsigned char. 74*a3e9eb18Smrg return std::tolower((unsigned char)c); 7548fb7bfaSmrg } </pre><p>(Thanks to James Kanze for assistance and suggestions on all of this.) 7648fb7bfaSmrg </p><p>Another common operation is trimming off excess whitespace. Much 7748fb7bfaSmrg like transformations, this task is trivial with the use of string's 7848fb7bfaSmrg <code class="code">find</code> family. These examples are broken into multiple 7948fb7bfaSmrg statements for readability: 8048fb7bfaSmrg </p><pre class="programlisting"> 8148fb7bfaSmrg std::string str (" \t blah blah blah \n "); 8248fb7bfaSmrg 8348fb7bfaSmrg // trim leading whitespace 8448fb7bfaSmrg string::size_type notwhite = str.find_first_not_of(" \t\n"); 8548fb7bfaSmrg str.erase(0,notwhite); 8648fb7bfaSmrg 8748fb7bfaSmrg // trim trailing whitespace 8848fb7bfaSmrg notwhite = str.find_last_not_of(" \t\n"); 8948fb7bfaSmrg str.erase(notwhite+1); </pre><p>Obviously, the calls to <code class="code">find</code> could be inserted directly 9048fb7bfaSmrg into the calls to <code class="code">erase</code>, in case your compiler does not 9148fb7bfaSmrg optimize named temporaries out of existence. 9248fb7bfaSmrg </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="strings.string.case"></a>Case Sensitivity</h3></div></div></div><p> 9348fb7bfaSmrg </p><p>The well-known-and-if-it-isn't-well-known-it-ought-to-be 9448fb7bfaSmrg <a class="link" href="http://www.gotw.ca/gotw/" target="_top">Guru of the Week</a> 9548fb7bfaSmrg discussions held on Usenet covered this topic in January of 1998. 9648fb7bfaSmrg Briefly, the challenge was, <span class="quote">“<span class="quote">write a 'ci_string' class which 9748fb7bfaSmrg is identical to the standard 'string' class, but is 9848fb7bfaSmrg case-insensitive in the same way as the (common but nonstandard) 9948fb7bfaSmrg C function stricmp()</span>”</span>. 10048fb7bfaSmrg </p><pre class="programlisting"> 10148fb7bfaSmrg ci_string s( "AbCdE" ); 10248fb7bfaSmrg 10348fb7bfaSmrg // case insensitive 10448fb7bfaSmrg assert( s == "abcde" ); 10548fb7bfaSmrg assert( s == "ABCDE" ); 10648fb7bfaSmrg 10748fb7bfaSmrg // still case-preserving, of course 10848fb7bfaSmrg assert( strcmp( s.c_str(), "AbCdE" ) == 0 ); 10948fb7bfaSmrg assert( strcmp( s.c_str(), "abcde" ) != 0 ); </pre><p>The solution is surprisingly easy. The original answer was 11048fb7bfaSmrg posted on Usenet, and a revised version appears in Herb Sutter's 11148fb7bfaSmrg book <span class="emphasis"><em>Exceptional C++</em></span> and on his website as <a class="link" href="http://www.gotw.ca/gotw/029.htm" target="_top">GotW 29</a>. 11248fb7bfaSmrg </p><p>See? Told you it was easy!</p><p> 11348fb7bfaSmrg <span class="emphasis"><em>Added June 2000:</em></span> The May 2000 issue of C++ 11448fb7bfaSmrg Report contains a fascinating <a class="link" href="http://lafstern.org/matt/col2_new.pdf" target="_top"> article</a> by 11548fb7bfaSmrg Matt Austern (yes, <span class="emphasis"><em>the</em></span> Matt Austern) on why 11648fb7bfaSmrg case-insensitive comparisons are not as easy as they seem, and 11748fb7bfaSmrg why creating a class is the <span class="emphasis"><em>wrong</em></span> way to go 11848fb7bfaSmrg about it in production code. (The GotW answer mentions one of 11948fb7bfaSmrg the principle difficulties; his article mentions more.) 12048fb7bfaSmrg </p><p>Basically, this is "easy" only if you ignore some things, 12148fb7bfaSmrg things which may be too important to your program to ignore. (I chose 12248fb7bfaSmrg to ignore them when originally writing this entry, and am surprised 12348fb7bfaSmrg that nobody ever called me on it...) The GotW question and answer 12448fb7bfaSmrg remain useful instructional tools, however. 12548fb7bfaSmrg </p><p><span class="emphasis"><em>Added September 2000:</em></span> James Kanze provided a link to a 12648fb7bfaSmrg <a class="link" href="http://www.unicode.org/reports/tr21/tr21-5.html" target="_top">Unicode 12748fb7bfaSmrg Technical Report discussing case handling</a>, which provides some 12848fb7bfaSmrg very good information. 12948fb7bfaSmrg </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="strings.string.character_types"></a>Arbitrary Character Types</h3></div></div></div><p> 13048fb7bfaSmrg </p><p>The <code class="code">std::basic_string</code> is tantalizingly general, in that 13148fb7bfaSmrg it is parameterized on the type of the characters which it holds. 13248fb7bfaSmrg In theory, you could whip up a Unicode character class and instantiate 13348fb7bfaSmrg <code class="code">std::basic_string<my_unicode_char></code>, or assuming 13448fb7bfaSmrg that integers are wider than characters on your platform, maybe just 13548fb7bfaSmrg declare variables of type <code class="code">std::basic_string<int></code>. 13648fb7bfaSmrg </p><p>That's the theory. Remember however that basic_string has additional 13748fb7bfaSmrg type parameters, which take default arguments based on the character 13848fb7bfaSmrg type (called <code class="code">CharT</code> here): 13948fb7bfaSmrg </p><pre class="programlisting"> 14048fb7bfaSmrg template <typename CharT, 14148fb7bfaSmrg typename Traits = char_traits<CharT>, 14248fb7bfaSmrg typename Alloc = allocator<CharT> > 14348fb7bfaSmrg class basic_string { .... };</pre><p>Now, <code class="code">allocator<CharT></code> will probably Do The Right 14448fb7bfaSmrg Thing by default, unless you need to implement your own allocator 14548fb7bfaSmrg for your characters. 14648fb7bfaSmrg </p><p>But <code class="code">char_traits</code> takes more work. The char_traits 14748fb7bfaSmrg template is <span class="emphasis"><em>declared</em></span> but not <span class="emphasis"><em>defined</em></span>. 14848fb7bfaSmrg That means there is only 14948fb7bfaSmrg </p><pre class="programlisting"> 15048fb7bfaSmrg template <typename CharT> 15148fb7bfaSmrg struct char_traits 15248fb7bfaSmrg { 15348fb7bfaSmrg static void foo (type1 x, type2 y); 15448fb7bfaSmrg ... 15548fb7bfaSmrg };</pre><p>and functions such as char_traits<CharT>::foo() are not 15648fb7bfaSmrg actually defined anywhere for the general case. The C++ standard 15748fb7bfaSmrg permits this, because writing such a definition to fit all possible 15848fb7bfaSmrg CharT's cannot be done. 15948fb7bfaSmrg </p><p>The C++ standard also requires that char_traits be specialized for 16048fb7bfaSmrg instantiations of <code class="code">char</code> and <code class="code">wchar_t</code>, and it 16148fb7bfaSmrg is these template specializations that permit entities like 16248fb7bfaSmrg <code class="code">basic_string<char,char_traits<char>></code> to work. 16348fb7bfaSmrg </p><p>If you want to use character types other than char and wchar_t, 16448fb7bfaSmrg such as <code class="code">unsigned char</code> and <code class="code">int</code>, you will 16548fb7bfaSmrg need suitable specializations for them. For a time, in earlier 16648fb7bfaSmrg versions of GCC, there was a mostly-correct implementation that 16748fb7bfaSmrg let programmers be lazy but it broke under many situations, so it 16848fb7bfaSmrg was removed. GCC 3.4 introduced a new implementation that mostly 16948fb7bfaSmrg works and can be specialized even for <code class="code">int</code> and other 17048fb7bfaSmrg built-in types. 17148fb7bfaSmrg </p><p>If you want to use your own special character class, then you have 17248fb7bfaSmrg <a class="link" href="http://gcc.gnu.org/ml/libstdc++/2002-08/msg00163.html" target="_top">a lot 17348fb7bfaSmrg of work to do</a>, especially if you with to use i18n features 17448fb7bfaSmrg (facets require traits information but don't have a traits argument). 17548fb7bfaSmrg </p><p>Another example of how to specialize char_traits was given <a class="link" href="http://gcc.gnu.org/ml/libstdc++/2002-08/msg00260.html" target="_top">on the 17648fb7bfaSmrg mailing list</a> and at a later date was put into the file <code class="code"> 17748fb7bfaSmrg include/ext/pod_char_traits.h</code>. We agree 17848fb7bfaSmrg that the way it's used with basic_string (scroll down to main()) 17948fb7bfaSmrg doesn't look nice, but that's because <a class="link" href="http://gcc.gnu.org/ml/libstdc++/2002-08/msg00236.html" target="_top">the 18048fb7bfaSmrg nice-looking first attempt</a> turned out to <a class="link" href="http://gcc.gnu.org/ml/libstdc++/2002-08/msg00242.html" target="_top">not 18148fb7bfaSmrg be conforming C++</a>, due to the rule that CharT must be a POD. 18248fb7bfaSmrg (See how tricky this is?) 18348fb7bfaSmrg </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="strings.string.token"></a>Tokenizing</h3></div></div></div><p> 18448fb7bfaSmrg </p><p>The Standard C (and C++) function <code class="code">strtok()</code> leaves a lot to 18548fb7bfaSmrg be desired in terms of user-friendliness. It's unintuitive, it 18648fb7bfaSmrg destroys the character string on which it operates, and it requires 18748fb7bfaSmrg you to handle all the memory problems. But it does let the client 18848fb7bfaSmrg code decide what to use to break the string into pieces; it allows 18948fb7bfaSmrg you to choose the "whitespace," so to speak. 19048fb7bfaSmrg </p><p>A C++ implementation lets us keep the good things and fix those 19148fb7bfaSmrg annoyances. The implementation here is more intuitive (you only 19248fb7bfaSmrg call it once, not in a loop with varying argument), it does not 19348fb7bfaSmrg affect the original string at all, and all the memory allocation 19448fb7bfaSmrg is handled for you. 19548fb7bfaSmrg </p><p>It's called stringtok, and it's a template function. Sources are 19648fb7bfaSmrg as below, in a less-portable form than it could be, to keep this 19748fb7bfaSmrg example simple (for example, see the comments on what kind of 19848fb7bfaSmrg string it will accept). 19948fb7bfaSmrg </p><pre class="programlisting"> 20048fb7bfaSmrg#include <string> 20148fb7bfaSmrgtemplate <typename Container> 20248fb7bfaSmrgvoid 20348fb7bfaSmrgstringtok(Container &container, string const &in, 20448fb7bfaSmrg const char * const delimiters = " \t\n") 20548fb7bfaSmrg{ 20648fb7bfaSmrg const string::size_type len = in.length(); 20748fb7bfaSmrg string::size_type i = 0; 20848fb7bfaSmrg 20948fb7bfaSmrg while (i < len) 21048fb7bfaSmrg { 21148fb7bfaSmrg // Eat leading whitespace 21248fb7bfaSmrg i = in.find_first_not_of(delimiters, i); 21348fb7bfaSmrg if (i == string::npos) 21448fb7bfaSmrg return; // Nothing left but white space 21548fb7bfaSmrg 21648fb7bfaSmrg // Find the end of the token 21748fb7bfaSmrg string::size_type j = in.find_first_of(delimiters, i); 21848fb7bfaSmrg 21948fb7bfaSmrg // Push token 22048fb7bfaSmrg if (j == string::npos) 22148fb7bfaSmrg { 22248fb7bfaSmrg container.push_back(in.substr(i)); 22348fb7bfaSmrg return; 22448fb7bfaSmrg } 22548fb7bfaSmrg else 22648fb7bfaSmrg container.push_back(in.substr(i, j-i)); 22748fb7bfaSmrg 22848fb7bfaSmrg // Set up for next loop 22948fb7bfaSmrg i = j + 1; 23048fb7bfaSmrg } 23148fb7bfaSmrg} 23248fb7bfaSmrg</pre><p> 23348fb7bfaSmrg The author uses a more general (but less readable) form of it for 23448fb7bfaSmrg parsing command strings and the like. If you compiled and ran this 23548fb7bfaSmrg code using it: 23648fb7bfaSmrg </p><pre class="programlisting"> 23748fb7bfaSmrg std::list<string> ls; 23848fb7bfaSmrg stringtok (ls, " this \t is\t\n a test "); 23948fb7bfaSmrg for (std::list<string>const_iterator i = ls.begin(); 24048fb7bfaSmrg i != ls.end(); ++i) 24148fb7bfaSmrg { 24248fb7bfaSmrg std::cerr << ':' << (*i) << ":\n"; 24348fb7bfaSmrg } </pre><p>You would see this as output: 24448fb7bfaSmrg </p><pre class="programlisting"> 24548fb7bfaSmrg :this: 24648fb7bfaSmrg :is: 24748fb7bfaSmrg :a: 24848fb7bfaSmrg :test: </pre><p>with all the whitespace removed. The original <code class="code">s</code> is still 24948fb7bfaSmrg available for use, <code class="code">ls</code> will clean up after itself, and 25048fb7bfaSmrg <code class="code">ls.size()</code> will return how many tokens there were. 25148fb7bfaSmrg </p><p>As always, there is a price paid here, in that stringtok is not 25248fb7bfaSmrg as fast as strtok. The other benefits usually outweigh that, however. 25348fb7bfaSmrg </p><p><span class="emphasis"><em>Added February 2001:</em></span> Mark Wilden pointed out that the 25448fb7bfaSmrg standard <code class="code">std::getline()</code> function can be used with standard 25548fb7bfaSmrg <code class="code">istringstreams</code> to perform 25648fb7bfaSmrg tokenizing as well. Build an istringstream from the input text, 25748fb7bfaSmrg and then use std::getline with varying delimiters (the three-argument 25848fb7bfaSmrg signature) to extract tokens into a string. 25948fb7bfaSmrg </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="strings.string.shrink"></a>Shrink to Fit</h3></div></div></div><p> 26048fb7bfaSmrg </p><p>From GCC 3.4 calling <code class="code">s.reserve(res)</code> on a 26148fb7bfaSmrg <code class="code">string s</code> with <code class="code">res < s.capacity()</code> will 26248fb7bfaSmrg reduce the string's capacity to <code class="code">std::max(s.size(), res)</code>. 26348fb7bfaSmrg </p><p>This behaviour is suggested, but not required by the standard. Prior 26448fb7bfaSmrg to GCC 3.4 the following alternative can be used instead 26548fb7bfaSmrg </p><pre class="programlisting"> 26648fb7bfaSmrg std::string(str.data(), str.size()).swap(str); 26748fb7bfaSmrg </pre><p>This is similar to the idiom for reducing 26848fb7bfaSmrg a <code class="code">vector</code>'s memory usage 26948fb7bfaSmrg (see <a class="link" href="../faq.html#faq.size_equals_capacity" title="7.8.">this FAQ 27048fb7bfaSmrg entry</a>) but the regular copy constructor cannot be used 2714d5abbe8Smrg because libstdc++'s <code class="code">string</code> is Copy-On-Write in GCC 3. 27248fb7bfaSmrg </p><p>In <a class="link" href="status.html#status.iso.2011" title="C++ 2011">C++11</a> mode you can call 27348fb7bfaSmrg <code class="code">s.shrink_to_fit()</code> to achieve the same effect as 27448fb7bfaSmrg <code class="code">s.reserve(s.size())</code>. 27548fb7bfaSmrg </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="strings.string.Cstring"></a>CString (MFC)</h3></div></div></div><p> 27648fb7bfaSmrg </p><p>A common lament seen in various newsgroups deals with the Standard 27748fb7bfaSmrg string class as opposed to the Microsoft Foundation Class called 27848fb7bfaSmrg CString. Often programmers realize that a standard portable 27948fb7bfaSmrg answer is better than a proprietary nonportable one, but in porting 28048fb7bfaSmrg their application from a Win32 platform, they discover that they 28148fb7bfaSmrg are relying on special functions offered by the CString class. 28248fb7bfaSmrg </p><p>Things are not as bad as they seem. In 28348fb7bfaSmrg <a class="link" href="http://gcc.gnu.org/ml/gcc/1999-04n/msg00236.html" target="_top">this 28448fb7bfaSmrg message</a>, Joe Buck points out a few very important things: 28548fb7bfaSmrg </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>The Standard <code class="code">string</code> supports all the operations 28648fb7bfaSmrg that CString does, with three exceptions. 28748fb7bfaSmrg </p></li><li class="listitem"><p>Two of those exceptions (whitespace trimming and case 28848fb7bfaSmrg conversion) are trivial to implement. In fact, we do so 28948fb7bfaSmrg on this page. 29048fb7bfaSmrg </p></li><li class="listitem"><p>The third is <code class="code">CString::Format</code>, which allows formatting 29148fb7bfaSmrg in the style of <code class="code">sprintf</code>. This deserves some mention: 29248fb7bfaSmrg </p></li></ul></div><p> 29348fb7bfaSmrg The old libg++ library had a function called form(), which did much 29448fb7bfaSmrg the same thing. But for a Standard solution, you should use the 29548fb7bfaSmrg stringstream classes. These are the bridge between the iostream 29648fb7bfaSmrg hierarchy and the string class, and they operate with regular 29748fb7bfaSmrg streams seamlessly because they inherit from the iostream 29848fb7bfaSmrg hierarchy. An quick example: 29948fb7bfaSmrg </p><pre class="programlisting"> 30048fb7bfaSmrg #include <iostream> 30148fb7bfaSmrg #include <string> 30248fb7bfaSmrg #include <sstream> 30348fb7bfaSmrg 30448fb7bfaSmrg string f (string& incoming) // incoming is "foo N" 30548fb7bfaSmrg { 30648fb7bfaSmrg istringstream incoming_stream(incoming); 30748fb7bfaSmrg string the_word; 30848fb7bfaSmrg int the_number; 30948fb7bfaSmrg 31048fb7bfaSmrg incoming_stream >> the_word // extract "foo" 31148fb7bfaSmrg >> the_number; // extract N 31248fb7bfaSmrg 31348fb7bfaSmrg ostringstream output_stream; 31448fb7bfaSmrg output_stream << "The word was " << the_word 31548fb7bfaSmrg << " and 3*N was " << (3*the_number); 31648fb7bfaSmrg 31748fb7bfaSmrg return output_stream.str(); 31848fb7bfaSmrg } </pre><p>A serious problem with CString is a design bug in its memory 31948fb7bfaSmrg allocation. Specifically, quoting from that same message: 32048fb7bfaSmrg </p><pre class="programlisting"> 32148fb7bfaSmrg CString suffers from a common programming error that results in 32248fb7bfaSmrg poor performance. Consider the following code: 32348fb7bfaSmrg 32448fb7bfaSmrg CString n_copies_of (const CString& foo, unsigned n) 32548fb7bfaSmrg { 32648fb7bfaSmrg CString tmp; 32748fb7bfaSmrg for (unsigned i = 0; i < n; i++) 32848fb7bfaSmrg tmp += foo; 32948fb7bfaSmrg return tmp; 33048fb7bfaSmrg } 33148fb7bfaSmrg 33248fb7bfaSmrg This function is O(n^2), not O(n). The reason is that each += 33348fb7bfaSmrg causes a reallocation and copy of the existing string. Microsoft 33448fb7bfaSmrg applications are full of this kind of thing (quadratic performance 33548fb7bfaSmrg on tasks that can be done in linear time) -- on the other hand, 33648fb7bfaSmrg we should be thankful, as it's created such a big market for high-end 33748fb7bfaSmrg ix86 hardware. :-) 33848fb7bfaSmrg 33948fb7bfaSmrg If you replace CString with string in the above function, the 34048fb7bfaSmrg performance is O(n). 34148fb7bfaSmrg </pre><p>Joe Buck also pointed out some other things to keep in mind when 34248fb7bfaSmrg comparing CString and the Standard string class: 34348fb7bfaSmrg </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>CString permits access to its internal representation; coders 34448fb7bfaSmrg who exploited that may have problems moving to <code class="code">string</code>. 34548fb7bfaSmrg </p></li><li class="listitem"><p>Microsoft ships the source to CString (in the files 34648fb7bfaSmrg MFC\SRC\Str{core,ex}.cpp), so you could fix the allocation 34748fb7bfaSmrg bug and rebuild your MFC libraries. 34848fb7bfaSmrg <span class="emphasis"><em><span class="emphasis"><em>Note:</em></span> It looks like the CString shipped 34948fb7bfaSmrg with VC++6.0 has fixed this, although it may in fact have been 35048fb7bfaSmrg one of the VC++ SPs that did it.</em></span> 35148fb7bfaSmrg </p></li><li class="listitem"><p><code class="code">string</code> operations like this have O(n) complexity 35248fb7bfaSmrg <span class="emphasis"><em>if the implementors do it correctly</em></span>. The libstdc++ 35348fb7bfaSmrg implementors did it correctly. Other vendors might not. 3544d5abbe8Smrg </p></li><li class="listitem"><p>While parts of the SGI STL are used in libstdc++, their 35548fb7bfaSmrg string class is not. The SGI <code class="code">string</code> is essentially 35648fb7bfaSmrg <code class="code">vector<char></code> and does not do any reference 35748fb7bfaSmrg counting like libstdc++'s does. (It is O(n), though.) 35848fb7bfaSmrg So if you're thinking about SGI's string or rope classes, 35948fb7bfaSmrg you're now looking at four possibilities: CString, the 36048fb7bfaSmrg libstdc++ string, the SGI string, and the SGI rope, and this 36148fb7bfaSmrg is all before any allocator or traits customizations! (More 36248fb7bfaSmrg choices than you can shake a stick at -- want fries with that?) 36348fb7bfaSmrg </p></li></ul></div></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="traits.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="std_contents.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="localization.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Traits </td><td width="20%" align="center"><a accesskey="h" href="../index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 8. 36448fb7bfaSmrg Localization 36548fb7bfaSmrg 36648fb7bfaSmrg</td></tr></table></div></body></html>