Re: Q about ctype.narrow

[Martin Sebor <sebor at roguewave dot com>]

Pétur Runólfsson wrote:

...
> > This usage was also, I'm sure, not intended -- the (admittedly
> > non-normative) note in 22.1.1, p5 makes it pretty clear, IMO:
> >
> >   -5- [Note: All locale semantics are accessed via use_facet<>
> >       and has_facet<>, except that: ...
> >
> > I.e., you have to install a facet in a locale before calling any
> > of its member functions, and you can only call them after a call
> > to use_facet on that locale. Our implementation even relies on
> > it (i.e., some facets, including ctype, will not work correctly
> > otherwise).
>
>
> That's not how I read that note. I read it as "The only way to get
> information out of locale objects is through use_facet<> and
> has_facet<>, except that...". In other words, I read it only as a
> statement about class locale, not about localization in general.
> This reading seems to make the most sense, since a) it is backed
> by normative text, and b) this note appears in the description of
> class locale.

I don't think this interpretation is plausible. To see why not,
consider all the byname facets whose constructors are completely
unspecified, making the behavior of such things as ctype_byname
ctor and thus the semantics of member functions invoked on such
constructed objects unspecified as well. The only way to obtain
any byname facet with predictable semantics is to first construct
a locale object and then extract the facet from it by calling
use_facet.

Whatever the original intent of the Note, though, it doesn't seem
reasonable to constrain the rule to just facets installed in locale
objects. The goal has always been to allow implementations to be
efficient. With your constraint, cached implementations would not
be possible (without undue effort on part of the implementor).
Since an arbitrary facet object has no way of knowing whether it
is or isn't installed in a locale, it could not implement any
caching at all.

Martin