On Tue, Oct 11, 2005 at 05:07:44PM -0400, Gennadiy Rozental wrote:
The way I see it all string algorithms should be using class like const_string in their interfaces. basic_string should implement const_string interface. I really think we need to provide this within boost (I know there is something in queue - lets where it will go)
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.
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.
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. 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. I'm not saying that this is the only possible abstraction, but it has proven adequate. Regards, Pavol