From 5959861769883730431 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,cc1a555bbe9617a3 X-Google-Attributes: gidf78e5,public From: "Bill Wade" Subject: Re: STL and SGI and strings Date: 1998/01/15 Message-ID: <69lj8l$o4e$1@uuneo.neosoft.com>#1/1 X-Deja-AN: 316414516 References: <34B57837.41C6@pixar.com><34B6580F.6A50@pratique.fr><34BAA6FB.17121A3E@acm.org><34BB973F.167EB0E7@pratique.fr><69igmc$3gq$1@uuneo.neosoft.com> X-Original-Date: Thu, 15 Jan 1998 12:05:13 -0600 Originator: austern@isolde.mti.sgi.com X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Organization: NeoSoft, Inc. X-Auth: PGPMoose V1.1 PGP comp.std.c++ iQBVAwUBNL7Krky4NqrwXLNJAQFPnQH+L+pqTp3cubbq32/G9tpv0XsL8Ym4Z1yd uqxs/EHIkb5b8FXt+W7cv/JUPg4vwNmx96nfeavM4XHYYt24l/PxMQ== =JI1Z Newsgroups: comp.std.c++ Matt Austern wrote in message ... >> Why does c_str() disallow sharing? It returns a pointer to const which >> remains valid only until a non-const member of the string is called. > >Ah, but that's exactly the point. s1.c_str() returns a pointer that >remains valid until a non-const member on s1 gets called. Non-const >members on copies of s1, though, are quite a different story. > > const char* p1 = s1.c_str(); > string s2 = s1; At this point s2 and s1 may have a shared representation. > s2[0] = '*'; // No non-const member of s1 has been called, > // so p1 is still valid. This means that > // p1 may not point to a [shared] region of storage At this point s1 and s2 may not have a completely shared representation. Any system using shared representations will most likely 'unshare' any string as soon as a non-const member (in this case op[]) is called. The unsharing must occur in a way which leaves p1 valid. Perhaps it is just a question of semantics. I would say that c_str did not prevent sharing, it was op[] which prevented sharing. If s1[0] != s2[0] it is hard to imagine the benefit of sharing element zero. I will admit that c_str makes "partial" sharing inefficient. In the absence of c_str it might make more sense to implement strings which share common substrings (along the lines of rope). More precisely, implementations with non-contiguous characters make c_str inefficient. I would guess that c_str was included in the standard because existing libraries take a lot of char* arguments, and people will want to pass string arguments to those libraries. I believe it would be a big step back to require programmers to write char* cname = new char[name.length()+1]; copy(name.begin(), name.end(), cname); cname[name.length()] = 0; remove(cname); delete[] cname; instead of remove(name.c_str()); I can't use vector for memory management, since an implementation is not required to make vector elements contiguous. There is no auto_array_ptr because vector is better ;-). The standard could have mandated that remove() be overloaded to take a string argument, but that doesn't help existing third party libraries. At worst c_str is implemented as shown above. In many implementations it is significantly better. I note that even rope provides c_str, even though it is not efficient. If I'm using strings in an environment where the need for c_str and op[] is rare, and concatenation of megabyte strings is common I'm sure you can suggest a better class. For an environment where most string operations 1) involve long strings 2) no multithreading 3) lots of assignment/copy construction 4) lots of c_str calls a typical shared string implementation seems appropriate. In an environment where the most common operation was string += char; a not-shared deque might be the best implementation. In this case I would argue that a deque implementation makes c_str inefficient, not that c_str makes concatenation inefficient, but I guess it just depends on how you look at it. --- [ comp.std.c++ is moderated. To submit articles: Try just posting with your newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html Comments? mailto:std-c++-request@ncar.ucar.edu ]