Migration to Unicode
Revision as of 10:48, 26 September 2012 by Alexander Kogtenkov (Talk | contribs) (→Temporary solution: Splitted item #4.)
This is a summary of the recommendations for adapting applications to handle Unicode.
General rule
- Never use
STRING_8or any variant of it unless you write a program that is going to be deleted in 5 minutes after running it. Do not even consider usingSTRING_8or its variant. Always useIMMUTABLE_STRING_32,READABLE_STRING_32orSTRING_32. - Do not use classes from third-party libraries that take
STRING_8rather thanSTRING_32.
Temporary solution
- Replace types using the following table:
| Old class | New class |
|---|---|
STRING_8
|
STRING_32
|
FILE_NAME
|
FILE_NAME_32
|
DIRECTORY_NAME
|
DIRECTORY_NAME_32
|
FILE
|
FILE_32
|
RAW_FILE
|
RAW_FILE_32
|
PLAIN_TEXT_FILE
|
PLAIN_TEXT_FILE_32
|
DIRECTORY
|
DIRECTORY_32
|
KL_BINARY_INPUT_FILE
|
KL_BINARY_INPUT_FILE_32
|
KL_TEXT_OUTPUT_FILE
|
KL_TEXT_OUTPUT_FILE_32
|
EXECUTION_ENVIRONMENT
|
EXECUTION_ENVIRONMENT_32
|
- Consider using
READABLE_STRING_32for argument types. If you cannot immediately change argument types to takeREADABLE_STRING_32, e.g. because this is a library class, useREADABLE_STRING_GENERALand perform all the necessary conversions inside the routine. - If you need to convert one UTF encoding into another one, use
UTF_CONVERTER. This is an expanded class, so it's possible to declare a local variable of this type and call features on it without explicit object creation. - Consider using
SHARED_EXECUTION_ENVIRONMENTto accessEXECUTION_ENVIRONMENT_32. - If you want to operate on files with an unknown string type for their names (i.e.
READABLE_STRING_GENERAL), useFILE_UTILITIES. This is an expanded class and can be used as described forUTF_CONVERTER.

