Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2011-01-26 10:48:52

On Wed, Jan 26, 2011 at 3:46 PM, Stewart, Robert <Robert.Stewart_at_[hidden]> wrote:
> Dean Michael Berris wrote:
>>
[snip/]
>> >> Sure, but still I don't see why you need to add c_str() to an
>> >> immutable string when you're fine to create an std::string
>> >> from that immutable string and call c_str() from the std::string
>> >> instance instead?
>> >
>> > One word. Performance :)
>>
>> So you're saying c_str() is a performance enhancing feature? Did you
>> consider that the reason why std::string concatenation is a bad
>> performance killer is precisely because it has to support c_str()?

Of course I have considered it, I have played with the SGI's
rope class in the past and it is great when you need to do
a lot of concatenations and the you *do not* call anything
related to c_str(). But c_str() is at least in my wold
something that I (unfortunately) have to call, until somebody
ports WINAPI, POSIX, etc. to C++ :)

>
> That's an interesting viewpoint. Â Note, however, that it is extremely common to build a string, piecewise, and then use it as an array of characters with some OS API. Â Those APIs won't change, so c_str(), in some form, is definitely needed. Â Furthermore, the piecewise assembly seems likely inefficient given and immutable string, especially one from which a contiguous array of characters is needed. Â Can you illustrate how that would be done and how it can be as efficient or more so than the status quo?

+1
I can imagine how various libraries could take great advantage
of "rope-like" string implementations, but there are unfortunately
very few that actually do so.

I would *love* this and other string-related or more specifically
text-handling-related things to change in the foreseeable future but
I am not going to hold my breath :)

>
>> I'd argue that converting an immutable string object (which doesn't
>> have to be stored as a contiguous chunk of memory unlike how C strings
>> are handled) to an std::string can be the (amortized constant) cost of
>> a segmented traversal of the same string.

Of course it can. But, will your string come with a new
version of CryptoAPI , etc., etc. ad nauseum :) that *will*
take advantage of it ? Until this happens I say we need
at least reasonably efficient implementation of c_str().

>
> That's quite interesting, but I'd argue that creating a std::string, which allocates a buffer on the free store to hold a duplicate of the sequence in the immutable string object can be unnecessary overhead should the immutable string already hold a contiguous array of characters. Â Thus, the sequence you suggest -- immutable string object to std::string to contiguous array of characters -- may be unnecessarily inefficient.
Exactly

Best,

Matus