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

From: Pavol Droba (droba_at_[hidden])
Date: 2005-10-12 00:50:51

On Tue, Oct 11, 2005 at 11:57:09PM -0400, Gennadiy Rozental wrote:

[snip]

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

This is very true. String is realy in most cases some_template<char_type>.
However this "some_template" is far more important for the algorithm, than
the "char_type"

Char_types are perfectly described by the means of locales, and there is usualy
no need to handle different char_type specificaly.

On the other hand, "some_template" can vary quite a lot. And for an algorithm,
that needs to make some manipulations on it, its interface is more important.

I think, that there is some misunderstanding here. You are talking about char_type,
but, that represents something different the iterator.
Iterators are abstraction of a container, while the char_type is an abstration
of a contained value.

Based on your presentation, there is bigger difference between
basic_string<char> and basic_string<wchar_t>, then between
basic_string<char> and FlexiString<char>.

IMHO it is precisely the opposite.

In addition I'd like to point out, that the string_algo library is not based on iterators,
rather on Ranges. Range is an encapsulation of an iterator, and it is the best
abstraction of a container we have so far.

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

But I would realy like know what leads you to an idea, that it is not adequate.
What is missing and what should be made differently? Can you provide a simple
example of an algorithm, that is written your way?

Regards,
Pavol