On Tue, Aug 21, 2012 at 6:09 AM, Graeme Geldenhuys <graemeg.li...@gmail.com> wrote: > Hi, > > On 21 August 2012 09:32, Mattias Gaertner <nc-gaert...@netcologne.de> wrote: >> >> IMO unicodestring should be the same on all platforms, because >> otherwise the character size switches per platform, > > > Please define "character" in your sentence above. Are you referring to > a Unicode codepoint, or a "printable character"? If the first, then 4 > bytes is always sufficient on all platforms. > >> The compiler already supports an UTF8String, right? >> If yes, then some functions can use UTF8String, some UnicodeString >> (=UTF-16) and the compiler magic will convert automatically. > > How I would wish for FPC to stop this ridiculous ambiguity that Delphi > enforces. Can't we just introduce UTF8String and UTF16String types. By > the name they clearly state what encoding the hold. A UnicodeString > type should mean any Unicode encoding, and defaults to UTF-8 under > *nix type systems and UTF-16 under Windows. Thus no performance loss > on any platform. After all the name "Unicode String" does not imply > UTF-16 only - as per the Unicode Standards. > > >> The difficult decision is what functions and types should use UTF-8 >> and what UTF-16. This may depend on the platform. > > As I said, if you use the correct default encoding on each platform > for the UnicodeString type, the problem you mention will not be a > problem any more. Linux will use UTF-8 by default, so file handling > and API was will work without any conversion. > > The whole RTL should use UnicodeString type, where the encoding is as > I described above. > > >> I guess there is no good solution for TStrings. Whatever string type is >> chosen, some programs will suffer. > > Why will some suffer? Simply default UnicodeString to the correct > encoding on each platform, and no performance issues and no > unnecessary conversions will occur.
Make much sense and AFAIK so far no one has said why this approach would not work. Marcos Douglas _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel