Marc Mutz wrote:
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()?
I assume you meant s = s.trim(); Well, that's very persuasive although I think it's harder to write something modifies a collection of objects in place -- no? Don't get me wrong, I'm pretty fond of immutable value types. Most of date_time is written as immutable value types with a couple exceptions. However, in this case I'm building on a base type that's already mutable and it seems to me that it's pretty natural to say s.replace_all(...).
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.
I'll take that as a queue to do nothing ;-) Jeff