Table of Contents
For the required specialization codecvt<wchar_t, char, mbstate_t> , conversions are made between the internal character set (always UCS4 on GNU/Linux) and whatever the currently selected locale for the LC_CTYPE category implements.
The two required specializations are implemented as follows:
ctype<char>
This is simple specialization. Implementing this was a piece of cake.
ctype<wchar_t>
This specialization, by specifying all the template parameters, pretty much ties the hands of implementors. As such, the implementation is straightforward, involving mcsrtombs for the conversions between char to wchar_t and wcsrtombs for conversions between wchar_t and char.
Neither of these two required specializations deals with Unicode characters.
How to deal with the global locale issue?
How to deal with different types than char, wchar_t?
Overlap between codecvt/ctype: narrow/widen
Mask typedef in codecvt_base, argument types in codecvt. what is know about this type?
Why mask* argument in codecvt?
Can this be made (more) generic? is there a simple way to straighten out the configure-time mess that is a by-product of this class?
Get the ctype<wchar_t>::mask stuff under control. Need to make some kind of static table, and not do lookup every time somebody hits the do_is... functions. Too bad we can't just redefine mask for ctype<wchar_t>
Rename abstract base class. See if just smash-overriding is a better approach. Clarify, add sanity to naming.
The GNU C Library . Copyright © 2007 FSF. Chapters 6 Character Set Handling and 7 Locales and Internationalization.
System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x) . Copyright © 1999 The Open Group/The Institute of Electrical and Electronics Engineers, Inc.. .