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