[fpc-devel] Unicode resource strings

Marcos Douglas md at delfire.net
Tue Aug 21 15:23:10 CEST 2012

On Tue, Aug 21, 2012 at 6:09 AM, Graeme Geldenhuys
<graemeg.lists at gmail.com> wrote:
> Hi,
> On 21 August 2012 09:32, Mattias Gaertner <nc-gaertnma at 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

More information about the fpc-devel mailing list