Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2011-01-26 05:33:24

On Wed, Jan 26, 2011 at 11:24 AM, Ivan Le Lann <ivan.lelann_at_[hidden]> wrote:
> Le mercredi 26 janvier 2011 à 09:29 +0100, Matus Chochlik a écrit :
>> On Tue, Jan 25, 2011 at 5:12 AM, Dean Michael Berris
>> <mikhailberis_at_[hidden]> wrote:
>> >
>>
>> Some years ago, when I first discovered the SGI's implementation
>> of STL and its rope class my first thought was 'Cool'.
>> Then I wrote a couple of (in the hindsight) rather synthetic
>> simple programs exploiting those cool features of rope
>> and it outperformed the std::string almost in every one of them.
>>
>> Then I tried to use it in a more real world scenarios, like for
>> example passing them to WINAPI. Then I returned to
>> std::string :)

I didn't say that the rope has been visibly less efficient
in this case, but the point is that it was not visibly more
efficient than string and at the time it was not standard.
I vaguely remember having some trouble getting it working
on Windows.

>>
>
> [ disclaimer: extremely premature implementation detail :) ]
>
> I don't know about SGI's rope internals.
> My understanding of rope in the real world use case you mention is that
> it does lazy "c_str" evaluation. Now, if you only give verbatim back to
> the OS a string it gave you, there is no reason for c_str to be slow.
> If you did string manipulation, then you'll pay for this at c_str call,
> but you had to pay for this eventually. I see no penalty here.
>
> To illustrate this, I understand an immutable rope as roughly :
>
> boost::make_recursive_variant <
> Â boost::shared_ptr <const std::basic_string <code_unit_type>>,
> Â boost::shared_ptr <const std::list <boost::recursive_variant_>>
>>::type
>
> Here c_str should be trivial in basic_string case.
>
Matus