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

[Martin Sebor]

Paolo Carlini wrote:

> Martin Sebor wrote:
> 
>> If I understand the issue correctly, the test case probably needs
>> to make sure that results returned from both forms of widen() are
>> consistent, even though the standard doesn't seem to explicitly
>> require it (there are a number of other inconsistencies in locale
>> due to this).
> 
> 
> FYI, you posted something very similar to the testcase in the PR
> in the STLPort forum, circa December, 2002:

I'm not sure what PR you're referring to but the test case below
eventually led a defect report that made it clear that the virtual
function results can be cached. See
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html#360

The test case below doesn't take into account the array form of
widen() so it's not complete.

> 
> #include <iostream>
> #include <locale>
> 
> struct Ctype: std::ctype<char>
> {
> char do_widen(char c) const {
>  return 'A' + c % 26;
> }
> };
> 
> int main()
> {
>  std::locale loc(std::locale::classic(), new Ctype);
>  loc = std::cout.imbue(loc);
>  std::cout << 123 << '\n';
>  std::cout.imbue(loc);
> }
> 
> If you basically concur with Nathan that using widen(array) is correct
> I will close the PR immediately, otherwise perhaps suspend it 'til the
> DR is really there...

If the test case is analogous to the above then yes, I agree that
the facet needs to make sure that the results returned from both
versions of do_widen() are consistent.

> 
> Out of curiosity, can you tell us what your library does?

With DR 360 accepted we now cache the results for efficiency. The
array form of our do_widen() calls the non-array form (which I agree
is suboptimal, but our num_put and other formatting facets do not
call the array form, so it's not as serious :)

Martin