Re: Q about ctype.narrow

[Paolo Carlini <pcarlini at unitus dot it>]

Hi,

Jerry Quinn wrote:

> > Is there any reason why the cache needs to be in ctype, rather than
> > in a separate class (like numpunct_cache)? Since the default is
> > usually known at compile time, something like this seems possible:
>
> It lets library users of ctype<char>.narrow get the optimization as
> well as uses within the library.
Naively, I'm with Jerry.

> [...] 
> > Then change
> > 
> > ctype<_CharT> const& __ctype = use_facet<ctype<_CharT> >(__loc);
> > if (__ctype.narrow(*__beg, 0) != '%')
> > 
> > to
> > 
> > narrow_cache<_CharT, '0'> const& __narrow_cache = ...;
> > if (__narrow_cache.narrow(*__beg) != '%')
> > 
> > This scheme also allows narrow to be cached for wchar_t. Since most
> > format strings passed to time_put::put only contain format
> > characters (such as %X %x %c %H etc.) it should be sufficient to
> > cache characters 0 to 128, and fall back to the virtual for higher
> > values:
>
> This can also be done within the ctype<wchar_t> facet instead.
>
> What is the benefit in this case of keeping the cache table elsewhere?
Yes, I'm with Jerry in not seeing clearly the benefit.

Actually, a few days ago, without going into too much detail I considered
the project rather simple: my prototype was simply the moneypunt facet,
its _M_initialize_moneypunct() call in the constructor, and the 
corresponding
code in gnu/monetary_members.cc fetching data from the underlying locale 
data.

I was hoping that something similar could be done as part of the ctype
constructor, basically filling a couple of tables with btowc/wctob.

I hasten to point out that my scope was therefore *limited*: the /default/
do_widen and do_narrow, not a general caching mechanism to be put inside 
widen
and narrow! Again, the current moneypunct virtuals were my example.

Wouldn't that be also quite useful in order to speed up many applications of
widen and narrow?

Paolo.