Re: [Boost-users] Report from Mont Tremblant C++ Committee meeting

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2005-10-11 22:57:09

>> > Are you 100% sure, that const_string is the only reasonable string
>> > representation?
>>
>> const_string is more interface then a representation. There possible some
>> design variations here
>
> This seems better, but I don't see any advantage to use it here instead of 
> iterators.

An advantage is that I do not need to care about iterator types.

>> > There are already several others (FlexiString, sgi's rope) and several 
>> > are
>> > already
>>
>> Non of them is standard, so no need to pay attention. Any *string* class
>> that want conform string_algo interface needs to satisfy const_string 
>> one.
>>
>
> None of the programs or classes I write are part of standard, yet the 
> standard
> library is designed to be used within them.
>
> Why are algorithms in stl not tied only to containers presented there?
>
> Sorry, but I think, that this view is very shorthanded.

STL does specify iterators and collections concepts that conforming class 
*required* to comply. The same situation here.

>> > announced (f.e. unicode_string).
>>
>> As for unicode string it's a separate issue IMO. I personally quite sure
>> that none of string algorithms will be applicable anyway. But this is 
>> topic
>> of separate discussion based on some real submission.
>>
>> > There has been so many discussions that monolithic
>> > approach is wrong, yet some people still argue in favor of them.
>>
>> All depends on what you mean by monolithic. IMO string algorithms design
>> should based in CharType/StringType not iterator type
>>
>
> I still don't see any good reason to it. String algorithms are primary 
> based
> on *strings* and not *char type*. A string is first of all a container.

Exactly - they are based on strings, not string iterators. But if we agree 
that all strings (we are interested to cover with this library) are 
parameterized by character type we could use char type parameterization

> As such thare are several options of its internal representation, none
> of them superior to other in all possible use cases.
>
> The only reasonble abstraction we have so far is through iterators.

IMO iterator abstraction is unnachural for strings. Unless we are talking 
about unicode in 99.99% of cases string is just some_template<char_type>

> I'm not saying that this is the only possible abstraction, but it has
> proven adequate.

It's proven implementable not adequate IMO

> Regards,
> Pavol

Regards,

Gennadiy