On Monday 03 July 2006 00:14, Jeff Garland wrote:
I assume you meant
s = s.trim();
After renaming trim_copy(), yes. Otherwise no.
Well, that's very persuasive although I think it's harder to write something modifies a collection of objects in place -- no?
Very good point. With a mutating trim(), people are tempted to write std::for_each( v.begin(), v.end(), mem_fn( &super_string::trim ) ); which, strictly speaking, is not explicitly allowed by the std, IIRC. With a const trimmed(), the user would be forced to use std:transform(v.begin(),v.end(),v.begin(),mem_fn(&super_string::trimmed)); which much better conveys what the code does.
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(...).
It's only natural b/c it's what people are used to. It's much easier, IMHO, to work with immutable types, b/c the interface is consistent. You have a point when you say that std::string is a mutable type and you're building on it. That doesn't mean, however, that you need to keep it's baggage. :) Marc -- Marc Mutz -- marc@klaralvdalens-datakonsult.se, mutz@kde.org phone: +49 521 521 45 45; mobile: +47 45 27 38 95 Klarälvdalens Datakonsult AB, Platform-independent software solutions