Boost logo

Boost :

From: Joel de Guzman (joel_at_[hidden])
Date: 2006-07-06 03:45:29

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


Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at