This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Rethinking... (Re: RFC: fp printing speedup...)
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