Re: [boost] Interest in super string class?

From: Marc Mutz (marc_at_[hidden])
Date: 2006-07-02 17:34:50

On Sunday 02 July 2006 23:09, Jeff Garland wrote:
>    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 :-)

Right. Therefore I'd make _copy the standard and not provide mutating variants 
at all. Who needs trim() and trim_copy() (or trimmed(), as I prefer to use 
English grammar to convey constness of member functions, where possible) if 
trim() can always be written as s = s.trim_copy()?

> >   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?

Well, operators are also mere functions. Instead of implementing a free op+, 
you implement a member replace() in the ET class, returning another 
instantiation of the ET, just like op+ would. Granted, it's more work to 
implement for the plethora of operations, and I can't readily see how to make 
this specific case of replace() any faster while preserving the ordering of 
replacements implied in the above (important for '&' in this case), but the 
point was that this kind of interface is open for these kinds of 
optimizations, though, on second thought, you could probably do the same 
thing with the dtor of the ET in the non-const case, too.

Marc

-- 
Marc Mutz -- marc_at_[hidden], mutz_at_[hidden]
Klarälvdalens Datakonsult AB, Platform-independent software solutions