Re: Q about ctype.narrow

[Martin Sebor <sebor at roguewave dot com>]

Pétur Runólfsson wrote:

...
> But they are specified, in 22.1.1.1.2 p3-4. (IMHO these paragraphs
> are in the wrong subclause. Since they describe constructors
> defined in 22.2, they should be in 22.2 also.)

You're right, I missed that. And I agree, they should also be
individually documented in 22.2.

>
...
> > Whatever the original intent of the Note, though, it doesn't seem
> > reasonable to constrain the rule to just facets installed in locale
> > objects.
>
>
> If you mean the note in 22.1.1, p7, I agree.

The Note in 22.1.1, p5:
    All locale semantics are accessed via use_facet<> and has_facet<>,
    except that: ...

> > The goal has always been to allow implementations to be
> > efficient.
>
>
> Maybe so; the question is whether that goal has been met.

If there's anything in the text that prevents an efficient
implementation it should be fixed. AFAICS, your interpretation
of the existing text is possible but, as I said, not desirable
for the sake of efficiency. If you agree I suggest that you
write up an issue (I'd be happy to help).

> > With your constraint, cached implementations would not
> > be possible (without undue effort on part of the implementor).
>
>
> If this sort of caching is allowed, there then there is no need
> for the ctype<char> specialization,  so it seems it wasn't
> intended when the facets where designed.

Well, I wasn't there when locale was being designed :) but my
impression from archived discussions is that the only purpose
of many/most facet member functions is to provide essentially
the semantics of "const" data members with default values that
can be overridden in derived classes and may potentially be lazily
initialized. I.e., the base facet ctor (or some function with
deferred initialization semantics) "initializes" the data member,
or an array thereof, to some default value and the ctor of a facet
derived from it may "reinitialize" it to a different value. After
the data member has been initialized by the most derived ctor its
value is fixed and may not change. Nathan might want to chime in
if he's following this thread.

The ctype<char> specialization most likely exists to avoid the
overhead of frequently called (otherwise virtual) functions. Why
some members (narrow(), widen(), etc.) are treated differently
than the classification functions I don't know (to keep the
footprint of the class down?) I stopped looking for consistency
in locale a long time ago ;-)

Martin