From: Jeff Garland (jeff_at_[hidden])
Date: 2006-07-02 18:14:42
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