Am 2017-05-05 um 12:16 schrieb Graeme Geldenhuys via Lazarus: > In the end it’s about supporting Unicode. Does it really matter > what internal encoding it is to achieve the “Unicode support” > goal?
From a performance perspective it may be unwanted to convert string encodings back and forth all the time. Although, in my file manager I use UTF-8 internally and convert to/from UTF-16 for all Windows API functions and I never found any problem with it. The time that the API functions requires is so much longer than the time for string conversion that it does not matter at all. Even fast API-functions like changing attributes only take a second for thousands of files. A situation where it may be a problem is when reading (UTF-16 encoded) text files. But I never stumbled over such a thing yet. I would promote the use of UTF-8 whereever possible while converting to target encodings only when unavoidable. It makes life much easier if you only concentrate on one (the best) Unicode encoding (UTF-8). Therefore I see no use of a UTF-16 bases RTL. I don't think that you would notice any performance difference to the UTF-8 based RTL. It would only waste valuable time that can be invested in other things. -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus-ide.org/listinfo/lazarus
