Re: [boost] [string] proposal

Subject: Re: [boost] [string] proposal
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2011-01-26 03:29:19

On Tue, Jan 25, 2011 at 5:12 AM, Dean Michael Berris
<mikhailberis_at_[hidden]> wrote:
> On Mon, Jan 24, 2011 at 7:36 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>> On Fri, Jan 21, 2011 at 5:00 PM, Ivan Le Lann <ivan.lelann_at_[hidden]> wrote:
>>>
>>> ----- "Nevin Liber" <nevin_at_[hidden]> wrote :
>>>
>>> Isn't rope worth a try here ?
>>
>> Absolutely!
>>
>
> +1 -- now if there was just a rope class that is part of the standard
> (and not an SGI extension) then it should definitely be a good
> candidate for how a string can efficiently store data without
> requiring linear memory complexity to the length of the text. :)
>
>> <shameless plug>
>> The author of rope is giving the keynote at BoostCon this year.
>> </shamelses>
>>
>
> Coolness. :)
>

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 :)

It would be awesome if for example (CryptoAPI's) CryptHashData
accepted a rope or a pair of generic iterators and could exploit
the coolness of its implementation but it does not. What it wants
is a BYTE* and length, which pretty much disqualifies any innovative
implementations of string, unless we want to dump all legacy APIs
and re-implement them. I don't want to say that the rope is useless,
but it is a very special case of string.

I would like to see the new string that comes out of this effort
to be adopted by new and is possible by existing libraries
and use them in their APIs, not just in the plumbing.

Matus