On Wed, Jan 26, 2011 at 3:46 PM, Stewart, Robert <Robert.Stewart@sig.com> 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