Re: [boost] Interest in super string class?

From: Martin Wille (mw8329_at_[hidden])
Date: 2006-07-06 05:08:12

Joel de Guzman wrote:
> Martin Wille wrote:

>> The collapsing views would produce a better quality output in the case
>> of ß, but I'm not sure the behaviour of compiletime composition
>> should differ from the behaviour of the runtime composition.
> 
> Yes, indeed. I realized that after some folks pointed that out.
> So collapsing to_upper/to_lower is not a good idea. But then, yes,
> the german: ß -> SS also implies that a universal to_lower/to_upper
> algorithm cannot be efficiently implemented as a mutating/in-place
> function (i.e. the string will have to grow/shrink). When such
> memory movement happens, the advantage of in-place mutation is
> gone.

True. I didn't intend to object to the functional model, anyway. (In
fact, I like it a lot and I'd prefer it most of the time.)

IMHO, the ongoing discussion highlights some fundamental disagreement on
what a string is/should be. There's an immutable string with free
functions group and a fat-interface string group. Either approach looks
wrong to me when taken alone.

String handling is the thing Java got basically right, IMHO. Java
distinguishes between a string class (immutable strings) and a string
builder class. Typically, immutable string classes are memory efficient
because they allow for sharing instances easily and time efficient
because they allows for easy passing of the strings into and out of
functions. String builders focus on modifying contents and intend to
save memory and execution time and to avoid memory fragmentation by
avoiding repeated allocation/copy/disposal sequences (even with views,
you'll sometimes need to save intermediate results and to work from
there in order to gain performance). std::string tries to be both and
that lead to a fat and somewhat confusing interface that is hard to
implement efficiently.

The proposed super string could be a nice string _builder_, while the
proposed functional/view interface could operate nicely on an immutable
string class, std::string and on the string builder.

Once we distinguish between a string builder and a string, most of the
confusing aspects of having two ways of doing the same thing go away.
Offering a generic, uniform approach to string handling, free functions
and views (supposedly) can work on any kind of string representation,
while the string builder can focus on efficient in-place transformations.

Use-cases in favor of either approach can be made. Consequently, there's
room for both suggested ways of dealing with character sequences and for
the libraries supporting them. What we need in order to avoid confusion
is to communicate clearly what the intent of the classes or
views/functions is. So if we add the suggested super string then PLEASE
do not name it 'string', but 'string_builder' or 'string_buffer' in
order to emphasize on the in-place modification aspect in the name. Of
course, there should be a complement to string_builder:
immutable_string. (ISTR there was a proposal for that, already).

Regards,
m
Send instant messages to your online friends http://au.messenger.yahoo.com