Re: [Patch] Fix libstdc++/13341 (speed-up <wchar_t>::do_narrow/widen)

[Paolo Carlini <pcarlini at unitus dot it>]

Nathan Myers wrote:

> It's necessary, and value-conserving, to cast any actual character
> value to unsigned char. Correct use of the C library ctype functions
> e.g. isdigit() requires that cast, e.g. isdigit((unsigned char)c) for
> values of c that might be outside the ASCII range.
>
> The widen and narrow members have the unusual property, among
> functions that operate on characters, that they only produce
> interesting results for characters that are in the "basic execution
> character set" (2.2). It includes a few control characters --
> tab, vt, ff, nl, bel, bs, cr, and nul -- the alphanumerics, the
> various cussword symbols excepting @ and $, and punctuation. They
> are all guaranteed to be non-negative when stored in a character,
> at least in the default "C" or "POSIX" locale.
>
> I don't know if this is helpful or entirely beside the point.

No, no, is helpful. In fact, my point about signedness, was not really
relevant. Sorry.

Thanks for pointing out that.

There are some other issues however, which we have to agree about
before going for 256:

1- Construction time doubled.
2- Memory usage doubled.
3- (pedantic, but once I got caught on the list! Blush!): we cannot
  assume in general 8 bits for a char, therefore, even with a 256
  elements table we cannot avoid completely the fallback to btowc,
  it seems... We should use limits<>...

Paolo.