Re: [boost] Interest in super string class?

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-07-03 09:08:54

Marc Mutz wrote:

> Very good point. With a mutating trim(), people are tempted to write
>   std::for_each( v.begin(), v.end(), mem_fn( &super_string::trim ) );
> which, strictly speaking, is not explicitly allowed by the std, IIRC. With a 
> const trimmed(), the user would be forced to use
>   std:transform(v.begin(),v.end(),v.begin(),mem_fn(&super_string::trimmed));
> which much better conveys what the code does.

There's no restriction on for_each.  I think the value of transform versus 
for_each for this case is marginal at best. As for trim versus trimmed, I'm 
afraid I don't like trimmed much.  It's 'past tense'.  To my ear it strikes as 
odd -- like the operation is already done.  I normally think of mutating 
functions a present tense verbs. Just looking around a bit, 
Boost.string_algo-trim, QTString-trimmed, Java.String-trim, RWCString-strip -- 
so it's not that consistent.  As much as anything I'm leveraging 
Boost.string_algo here, so consistent naming is a virtue.

Hopefully this won't make you mad, but your prior email made me realize that 
the mutating functions should return a self reference so now you can write:

  s.trim().to_upper().append(" more stuff ");

The other thing it made me realize is that it would be handy to have 
additional overloads on the number of parameters in append/insert_at. So in 
the next version you'll be able to write:

double dbl = 1.12345;
int i = 100;

s.append(dbl, " a string ", i);
//"1.12345 a string 100"

I'll probably do something like boost.tuple and support up to 10 arbitrary 
parameters.  And at the suggestion of someone else, I'm also adding 
boost.format into the mix:

s.append_formatted(dbl, "-some string-", i, "%-7.2f  %s %=5d");
//"1.12   -some string- 100  "

So I'm afraid I'm making it more mutable, not less ;-)

Jeff