Re: [boost] Interest in super string class?

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-07-04 15:03:01

Thorsten Ottosen wrote:
> Jeff Garland wrote:

>> It doesn't stop being easier to use -- it's the same every day.  Your implicit 
>> implication is that later on I'm going to find a bunch of extra functions that 
>> I can't perform with super_string.  True enough.  At that point I either add 
>> it to super_string or write it using the functional interface.  No big deal.
> 
> My implicit implication was that soon you'll feel comfortable with the
> free-standing functions.

Not likely, I've used free functions for years, but I'm going to the dark side 
now ;-)  Anyway, I've already responded to this point in detail elsewhere.  I 
agree, btw, that it can be done cleanly without a string type, but then you're 
going to need language support to do it well.

> In php, there is not a single member functions in a string, and all 
> string processing is done with free-standing functions. In general I 
> find strings in php easy to work with:
> 
> http://www.php.net/manual/en/ref.strings.php
> http://dk2.php.net/manual/en/ref.regex.php

I've written code in PHP as well.  It has the advantage over C++ in that it 
doesn't have templates to distract in the documentation.  But overall, I think 
PHP string handling is a mess...sorry.

>>> Not a good idea IMO.
>>
>> We disagree, obviously, and that's fine. Just to save some time, I'm pretty 
>> sure it's impossible to convince me that range or something else is going to 
>> solve my set of issues.
> 
> Probably not. I did not have that I mind. I think some extensions to 
> range will make stuff like regexes easier, but it would give you "one 
                                                     ^^^^^^
> place for all string processing".

Sorry -- do you mean 'wouldn't give'?

>> I'll just point out, that some of this was a result of recent brushes of mine 
>> with other languages. I've been doing some coding lately in, gasp, Java and 
>> Javascript.  As a diehard C++ developer, it ticks me off that I can sit down 
>> with the manual for these languages and in 15 minutes whip up some fancy 
>> string parsing code using regular expressions, etc.  It's all very nice and 
>> neat.  Go to the string reference page -- see the list of functions and boom, 
>> you're in business.  So it gets me thinking, why is it that C++ makes this so 
>> hard?  Well, std::string isn't as capable as Java's string.  Of course, C++ 
>> (with Boost) has all of the same capabilities, but it takes a truckload of 
>> documentation and a masters degree to figure it all out. And then it's a pain 
>> in the neck to use and read the code.  This is my attempt to rectify that.
> 
> If the problem is bad documentation/tutorials, then I think we should 
> fix that instead.

Nope, that's not really the problem.

> For Java, many many people have been paid to write the documentation, 

That's sad, a lot of it is pretty lousy as far as I'm concerned.

> whereas for boost, we have to do it our spare-time. It's pretty good 
> most of the time anyway.

I don't really have a problem with the documentation.  I think each of the 
various docs are good by themselves.  But as I mentioned before the functions 
are spread across a number of libraries. And, of course, the reference 
documentation has to be written in a totally generic fashion.  Just take 
regex_replace as a case in point:

template <class OutputIterator, class BidirectionalIterator, class traits, 
class charT>
OutputIterator regex_replace(OutputIterator out,
                            BidirectionalIterator first,
                            BidirectionalIterator last,
                            const basic_regex<charT, traits>& e,
                            const basic_string<charT>& fmt,
                            match_flag_type flags = match_default);

template <class traits, class charT>
basic_string<charT> regex_replace(const basic_string<charT>& s,
                             const basic_regex<charT, traits>& e,
                             const basic_string<charT>& fmt,
                             match_flag_type flags = match_default);

My first reaction when I read this is, wow, interesting, but how do I use it? 
  It's hard for even an experienced guy like me to see the forest from the 
template tree's here. So I scroll down to the example and start reading the 
example code. Ok, now I see it and I can go back, consume it, ponder 
more...then realize, ok I guess it's the second signature because I'm using an 
std::string...now I can go write some code.  (Of course, I normally don't do 
it like this because I go and look up some regex code I've already written).

Now lets compare JavaString.replaceAll (short description)

  String 	replaceAll(String regex, String replacement)
           Replaces each substring of this string that matches the given
           regular expression with the given replacement.

Wow, ok I don't need to see the example code, I can write code now.  I might 
need to read more about the regex string rules, but no biggie they follow 
expected conventions.  After 2 minutes I'm testing code.

Of course, JavaString.replaceAll is just lame compared to what regex can do. 
But, you know, it covers most of what I use for typical day to day string 
processing. It's clean, easy, fast -- I can focus on other parts of my app 
rather than the template parameters for the string function.

Now lets examine the hastily created *pre-alpha* super_string docs:

template<class char_type>
void basic_super_string< char_type >::replace_all_regex(
                 const base_string_type &  	match_regex,
                const base_string_type &  	replace_format)  	
           

Replace the all instance of the match_string with the replace_format.

     super_string s("(abc)3333()(456789) [123] (1) (cde)");

     //replace parens around digits with #--the digits--#
     s.replace_all_regex("\\(([0-9]+)\\)", "#--$1--#");

     //s == "(abc)3333()#--456789--# [123] #--1--# (cde)"

Right from the start there's only one signature and only one template 
parameter to document -- char_type is pretty easy to understand, doesn't even 
really require explanation -- but really the docs would be nicer without that 
distraction.  The context is string processing, so I don't have to worry about 
explaining the regex function can work on vector<char> or whatever sequence I 
want.  I've ditched a couple parameters of function parameters -- always going 
for the regex defaults. So super_string is more like JavaString -- very 
limited compared to full up regex or string_algo, but it's easier to document 
and use for common cases.

Jeff