On Fri, Sep 26, 2008 at 09:04, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote: > On Thu, Sep 25, 2008 at 10:33 PM, Florian Klaempfl > <[EMAIL PROTECTED]> wrote: >>
> I suppose it would be viable doing timing results for saving text > files as well. After all, 99% of the time, text files are stored in > UTF-8. So in D2009 you would first have to convert UTF-16 to UTF-8 and > then save. And the opposite when reading, plus checking for the byte > order marker. If you used UTF-8 for the String encoding no > conversions are required and no byte order marker checks needed. > That is true. But, on the other hand, 99% of your time, your application will work with string in memory, and only 1% of time will be spend on I/O. (Ok, this is for "normal" application, special cases like databases are special cases anyway). I don't really think that file encoding is strong argument regarding internal string representation. When you read text file, it's inevitable that you'll parse it in some way. And parsing is lot more slower than simple character conversions. I support decision of using UTF-16 over UTF-8. String processing is far more simpler, it's actually as simple as it should be. Have you ever done any serious processing using UTF-8? It's not nightmare, but it's surely real pain. No such problems with UTF-16. You don't need to thing about encodings & conversions all the time. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
