Re: [boost] Interest in super string class?

From: Sam Partington (sam.partington_at_[hidden])
Date: 2006-07-05 13:40:02

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