On Mon, Jan 19, 2015 at 5:23 AM, Jonathan Wakely <jwak...@redhat.com> wrote: > Maybe it's OK, because all the elements of __collatename use ASCII > chars which have the same value as wide chars? (Probably not true for > all locales).
I just noticed that if we want to implement it 100% accurately, narrowing down the input string to char string is clearly wrong, e.g. wchar_t wch = 0x1177; // 0x77, the default narrowed result, is 'w' std::wcout << std::regex_traits<wchar_t>().lookup_collatename(&wch, &wch+1) << L"\n"; // prints w So the correct approach is widening (and use ctype widen so that users can customize it) all char strings (those statically stored in these two functions), and compare them to the input range. But it seems to be slightly slower, so I wrote this implementation out of instinctively. Maybe people (now including me) always know that anything concerned with locales *are* slow? ;) > Your change is definitely an improvement and good enough for now > (maybe we should leave the Bugzilla PR open, with a note about the > wide char issue, and deal with it after stage4). I'm not sure how emergent we are, so I just go ahead and committed it. As I mentioned above, the right way to do this is widening the expected strings and compare them to the input string. Thanks! -- Regards, Tim Shen
