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

From: Pavol Droba (droba_at_[hidden])
Date: 2005-10-11 15:40:59

Hi,

On Tue, Oct 11, 2005 at 03:59:23PM -0400, Gennadiy Rozental wrote:
> >>There concern was that at least some of the algorithms were only useful in
> >>the context of strings, and so it would be an over-generalization to 
> >>supply
> >>them as free algorithms.
> >>
> >>One way to counter that argument would be to identify the functions you 
> >>have
> >>found useful on other containers, and to provide some use cases to 
> >>buttress
> >>the argument.
> >
> > Well, one thing I use it for is parsing HTTP directly in the read
> > buffer, which is a vector. If the interfaces weren't generic, I'd either
> > have to write my own functions to duplicate the functionality, or I'd
> > have to copy the incoming data to a string. The first seems silly, and
> > the latter would have unacceptable overhead in my case. The HTTP I'm
> > parsing is streaming video from several dozen cameras at once, so I have
> > to work with the buffers directly.
> >
> > I also use this library on plain old C strings, which wouldn't be
> > possible if it were locked to basic_string.
> >
> > Some changes may make sense, but I really like the way it is now.
> 
> 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?
There are already several others (FlexiString, sgi's rope) and several are already
announced (f.e. unicode_string). There has been so many discussions that monolithic
approach is wrong, yet some people still argue in favor of them. 

Original basic_string is mistake IMHO. It has overblown interface and yet it is
still not complete enough.

Regards,
Pavol.