Re: [boost] Interest in super string class?

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-07-02 17:09:12

Marc Mutz wrote:
> On Sunday 02 July 2006 03:03, Jeff Garland wrote:
>>    super_string s("    (456789) [123]  2006-10-01    abcdef   ");
>>    s.to_upper();
>>    cout << s << endl;
>>
>>    s.trim();  //lop of the whitespace on both sides
>>    cout << s << endl;
> 
> I really like this proposal, but have a minor point to add:
> IMHO, value classes should have much fewer mutating (non-const) (member) 
> functions. The above two examples are a very good example. to_upper() should 
> be const and return the string converted to uppercase, instead of performing 
> the operation on 'this'. Similarly, trim() should be trim_med_() and return a 
> trimmed copy of 'this'. This makes it much easier to work with such classes. 
> Qt4's QString has gone a long way towards this style of interface, but still 
> has a lot of annoying exceptions that make me mad most every day.

Well, I went about 50% of the way on this.  You'll notice that for some things 
there are non-modifying variations.

   basic_super_string trim_copy()       const;
   basic_super_string trim_left_copy()  const;
   basic_super_string trim_right_copy() const;

   basic_super_string to_lower_copy() const;
   basic_super_string to_upper_copy() const;

I just got tired and didn't add all the variations for replace_xxx.  Of course 
that makes the interface even fatter :-)

> The usual argument against is performance, and I agree performance is 
> important for a general-purpose string class. But what is often overlooked is 
> that the prefer-const-to-mutable-methods-style interface allows many more 
> optimisations than the classical style, if the implementor is willing to go 
> down the expression template path:
>   s = s.replace('&',"&amp;").replace('<',"&lt;).replace('\'','&apos;');
> can be made to execute a lot faster if replace is const than if it is not, b/c 
> it forces the return value of replace() to be evaluated.

I'm no expert in expression templates, but I don't think '.' can be overloaded 
-- how can ET do anything here?

> Maybe I'm talking common wisdom here, it's just something that I found 
> annoying in my everyday work and wanted to share. Feel free to ignore :)

I'll add replace_*_copy versions in the next rev...

Jeff