Rethinking... (Re: RFC: fp printing speedup...)

[Jerry Quinn <jlquinn at optonline dot net>]

Paolo Carlini writes:
 > >cache that is broken rather than the ctype<char> cache (which doesn't
 > >actually exist).
 > >
 > ... why don't we have it? Having it would in some way help for this
 > issue too?

No one has gotten to it yet.

 > I'm asking because I think that eventually we'll have it, because 'narrow',
 > 'widen', 'is' (we have already a PR for this: 11723) must be fast in order
 > to have an efficient implementation of the monetary and time facets.

We can certainly speed this stuff up.  Do we actually need a ctype
cache or just caches for money and time?  I don't think we can speed
up user code that accesses ctype.widen, since the spec says this must
call the virtual function.

Well, wait.  What if ctype.widen looked like:

CharT widen(char) {
  if (!cache) {
	cache = getcache();
	do_widen(cache.CharTarray, cache.chararry);
  }
  return cache.CharTarray[char];
}

Would this help the speed?

BTW, to me the standard looks very vague on the issue of whether array
widen must return the same results as char widen.  The standard says
that the array form transforms each character in the array.

Standards folk (Matt, Nathan, Martin) - do you know if the standard
intends that the following return true:

bool test(char c)
{
  ctype<charT> ct = use_facet...;
  char carray[1];
  carray[0] = c;	
  charT array[1];
  charT r = ct.do_widen(c);
  ct.do_widen(carray, carray+1, array);
  return r == array[0];
}

To me the standard seems to imply this, but no guarantees are given.
If the standard doesn't intend this to be true, that makes the array
form nearly useless, no?

If the standard does intend this to be the case, then we don't need to
loop with widen(char) and can use the array form instead.

Jerry