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

From: Pavol Droba (droba_at_[hidden])
Date: 2005-10-11 16:37:07

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