Boost logo

Boost :

Subject: Re: [boost] [string] proposal
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-01-26 09:46:28


Dean Michael Berris wrote:
> 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:
>
> > 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.

Based upon previous discussion, I think you need to present your case better for immutability. Others consider mutability to be an intrinsic and beneficial characteristic of a string class. You are proposing to drop that and assume all others implicitly understand why that would be good for all.

> >> 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()?

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?

> 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.

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.

_____
Rob Stewart robert.stewart_at_[hidden]
Software Engineer, Core Software using std::disclaimer;
Susquehanna International Group, LLP http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk