Jody said:
Sure, premature optimization is bad, but premature pessimization is worse. If you have two readily available and similarly easy to use interfaces, why would I want to use the one that incurs far more overhead?
Personally I'd prefer it to be an option that you can specify at call time. Something like to_upper(ref(s)); t = to_upper(s); Submit whatever word you like for 'ref', it could be 'in_place' or whatever. Of course that design would mandate the functional approach. Although I suppose with some clever proxying you could do in_place(s).replace('a', 'b'); My feeling is that member functions aren't right for algorithms because any extensions to a super_string library can't use the same natural syntax as the library provided functions. For example, I come up with a function String to_title_case(String s); I can't use it in the same way as I can to_upper. s = s.to_upper(); s = to_title_case(s); The inconsistency could be considered a good thing, because it makes it clear which functions are library provided and which are local. But I'm not so keen/
I assume you will answer that you'd prefer to only have the immutable interface available, so, whay is that, particularly in C++?
I think both should be available. The "you don't pay for what you don't use" principle applies here I think, if I don't need to make a copy, and in my application it matters, I should be able to avoid it. Sam