On Wed, Jan 26, 2011 at 5:10 PM, Matus Chochlik <chochlik@gmail.com> wrote:
On Wed, Jan 26, 2011 at 9:34 AM, Dean Michael Berris <mikhailberis@gmail.com> 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 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()? 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