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.