Martin Wille wrote:
Joel de Guzman wrote:
But it might be not: the question of what the result of to_upper(to_lower(to_upper(rng))) is supposed to be is not trivial at all. The result will be a view. Then, if it's done correctly, ideally, the view transformations can collapse the view. IOTW, this:
to_lower_view<to_upper_view<range> >
will be optimized to:
to_lower_view<range>
Hmm, I'm not convinced of that.
some_container tmp(to_upper_view(rng)); to_lower_view(tmp);
would return something different than
to_lower_view(to_upper_view(rng))
in languages which do not have a homomorphous characterwise mapping between lowercase and uppercase spelling (e.g. german: ß -> SS, but S -> s). For the same reason, a locale-aware to_upper_view would not be as trivial as one would think at first. (Not overly complex, either, probably).
The collapsing views would produce a better quality output in the case of ß, but I'm not sure the behaviour of compiletime composition should differ from the behaviour of the runtime composition.
Yes, indeed. I realized that after some folks pointed that out. So collapsing to_upper/to_lower is not a good idea. But then, yes, the german: ß -> SS also implies that a universal to_lower/to_upper algorithm cannot be efficiently implemented as a mutating/in-place function (i.e. the string will have to grow/shrink). When such memory movement happens, the advantage of in-place mutation is gone. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net