Marcos Douglas schrieb:
On Tue, Dec 24, 2013 at 3:18 AM, Hans-Peter Diettrich <[email protected]> wrote:
I started this thread. My problem isn't to use UTF-8 on Windows... my problem is use different encodings on the same code, ie, RTL <> LCL.
This mix would cause problems, of course.
Use functions, always, to convert string between RTL and LCL and vice-versa IHMO is wrong because the final code is confusing. In a huge application you still need to think "here is UTF-8 or ANSI/UTF-16?"
The simplest (feasable) solution IMO is the adaptation of (OS...) string types behind the scene, i.e. inside the RTL and widgetsets. Then you can have any common encoding in the application and library API, while encoding-dependent code is encapsulated in lower level functions receiving explicit (Unicode, UTF8String...) string types, so that the compiler can insert required conversions. Such explicit parameter types also were required for legacy code, where a specific encoding is assumed. I'm not sure how this conversion process can be automated or supported, perhaps removing/renaming the tradional UTF8... functions would help in spotting the procedures that require special attention.
The number of automatic conversions can be reduced in the next step, by e.g. adding overrides, or conditional code, for both string types one by one, as time permits.
DoDi -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
