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:
...
What we are really trying to clarify is if, overall, num_put::do_put should
behave as-if widen(char) is called (22.2.2.2.2, p14 seems to imply that) or
instead we are allowed to use the array version for performance sake.
I don't see why an implementation should be prohibited from calling
the array form as long as the results (other than any side-effects)
are the same. The standard does suggest that it's the non-array form
that must be called from stage 2, but I agree with Nathan that it
ought to be relaxed in order to allow an efficient implementation.
In other terms, your late-2002 snippet:
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);
}
what is supposed to output? "123" or "XYZ"? Is actually malformed ;)?
I'd say it's incomplete, but that the standard needs to be changed
to make it clear. With this facet, I believe it should print "XYZ"
struct Ctype: std::ctype<char>
{
char do_widen(char c) const {
return 'A' + c % 26;
}
const char* do_widen (cost char *lo, char *hi, char *to) {
for (; lo != hi; *to++ = Ctype::do_widen (*lo++));
return hi;
}
};
I think it will become simpler once we file an issue for this. Then
you can reference it in your PR and decide whether to pedantically
conform to the current overly restrictive requirements or whether
to implement the proposed resolution.
Martin