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('&',"&").replace('<',"<).replace('\'',''');
> > 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 Mutz -- marc_at_[hidden], mutz_at_[hidden] Klarälvdalens Datakonsult AB, Platform-independent software solutions
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk