Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-29 07:37:11

On Sat, Jan 29, 2011 at 8:07 PM, Ivan Le Lann <ivan.lelann_at_[hidden]> wrote:
>
> Dean Michael Berris wrote :
>
>>
>> But c_str() doesn't have to be part of the string's interface.
>
> *My* *guess* is that Artyom think that:
>
> Â os_func ((s1 + s2 + s3 + ... + s100).c_str()); // s for std::string
>
> is dramatically faster than:
>
> Â os_func ((c1 + c2 + c3 + ... + c100).to_string().c_str()); // c for "boost::chain"
>

And this is precisely my point as well: the one that uses boost::chain
is perfectly suited for this kind of use case in both efficiency and
clear-cut semantics. I for one don't like to make to_string() a member
either -- I much rather make it a conversion operator so boost::chain
(if we're going to call it that) can be used where interfaces take a
std::string.

Now the converted "linearized" version can be interned and reference
counted as well because it is guaranteed to never change but that's an
optimization that's unnecessary (yet) when we're talking about
interfaces. ;)

> Regardless of the validity of my present guess, I'm quite sure that this
> concern (and other similar ones) will be shared many developpers.
>

Which is valid. But then consider the case when your "c's" above are
really long strings.

-- 
Dean Michael Berris
about.me/deanberris