Subject: Re: [boost] [string] proposal
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-26 09:33:13
On Wed, Jan 26, 2011 at 5:10 PM, Matus Chochlik <chochlik_at_[hidden]> wrote:
> On Wed, Jan 26, 2011 at 9:34 AM, Dean Michael Berris
> <mikhailberis_at_[hidden]> wrote:
>> Well, see here's the key phrase there that's important:
>> Â "string manipulation"
>> I actually want to wipe that phrase off the face of the C++ world and
>> have everyone think in terms of "building strings" rather than
>> manipulating them because in reality, there really is no manipulating
>> something that's unique and immutable -- unless you create a new one
>> from it.
> OK, I Â think we think the same thing :) Looking at the aforementioned
> sources I found the doing things like:
> mystr[i] = whatever()
> was very rare, and while I used the term manipulation I didn't have
> this specific case in mind. I'm completely OK, if we all agree that
> what you propose is the way to go, with your idea how strings
> should be manip.. - er scratch that - built.
Agreed then as long as we stop thinking about manipulating strings
along the way. :D
> The immutability *does not* have a thing with the problems
> in the use-cases described above. Encoding *does*.
Right, so why should the encoding be part of the string then? I say
the encoding should be external to the string (which I've been saying
for the Nth time I think) and just a transformation on an input
string. The transformation doesn't even have to be immediate -- it
could and probably should be lazy. When you have immutable strings the
lazy application of transformations is really a game changer
especially in the way people (at least in C++) are used to when
dealing with strings.
>> 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
> 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()?
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.
So really, for performance reasons, I'd say an immutable string
converted to an std::string will cost you once -- and I'd say probably
just once for the lifetime of one immutable string especially if we
bolt on interning or similar goodies -- and the performance would be
pretty much predictable. Much like how you have to deal with
linearizing your data anyway when stuffing it into a socket, it's just
one of those things you've got to pay for at some point. ;)
-- Dean Michael Berris about.me/deanberris
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk