On Tue, Dec 24, 2013 at 12:22:41PM -0200, Marcos Douglas wrote: > > IMO the biggest group are old fashioned Delphi (D7) users, which want their > > existing Ansi/VCL code base supported *without* complications and > > incompatibilities introduced by the newer Delphi versions. The subject of > > this thread clearly indicates that UTF-8 is *not* a solution for this group > > of users. > > 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.
Yes. But the selection of UTF8, and the legacy concerns with that are for Lazarus, and lazarus alone. > 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?" There are many scenarios up in the sky, and nothing is 100% certain, but it would at least be significantly better. It is already significantly better in trunk. The only problem on Windows is that you must only pass a string with a very clear encoding to a RTL function. so assignfile(f,s+s2+s3); is dangerous if they are not all the same encoding. If there is any mismatch, it will be converted down to default encoding. It is defined, but somewhat special. > > That's my conclusion as well. But is that new audience worth to abandon the > > entire existing Lazarus audience? > > Of course nobody will abandon the entire existing Lazarus audience. If > the RTL will be UTF-16, UTF-32, whatever the Lazarus will continues -- > I think -- working using UTF-8. There is no utf8 on Windows. One can try to mess with the defaultcodepage, but that will probably only force a different kind of problems. On Windows there is only ansi or utf16, or keeping it manual. -- _______________________________________________ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
