[fpc-devel] Unicode resource strings

[Florian Klämpfl]

Am 20.08.2012 18:05, schrieb Graeme Geldenhuys:
> Hi,
> 
> On 20 August 2012 15:43, Florian Klämpfl <florian at freepascal.org> wrote:
>> Besides the resourcestrings I'am not aware of any unicodestring issues
>> in the *compiler*. If there are, please report them to the issue tracker.
> 
> 
> I have heard various back-and-forth comments about UnicodeString and
> others, which makes me believe the compiler+unicode is still
> incomplete, or at least not set in stone (understood as: don't really
> use, because it could still change).

True, it's not yet released but in 2.7.1 aka trunk for development,
testing and bug fixing.

> 
> For example:
> 
>   * new mode 'delphiunicode' was introduced, but what about developers
> wanting Unicode,
>     but the project is a pure FPC project (it has no history of Delphi)?

Then use {$mode objfpc} {$modeswitch unicodestrings}

{$mode delphiunicode} is for people who try to compile delphi code with
least as possible effort.

> 
>   * Only in 'delphiunicode' mode is String = UnicodeString (I guess
> the same issue as above)

See above.

> 
>   * All other modes String = AnsiString or ShortString based on {$H+}
> or not. String is the most
>     used type, and so too is the objfpc mode. So shouldn't String =
> UnicodeString in FPC 2.8.0 release
>     for mode objfpc too?

No, it breaks old code for nothing. We can add an objfpcunicode mode or
whatever you like.

> 
>   * UnicodeString is always UTF-16 (so everything but Windows takes a
> conversion penalty)!

A decision has been made and you are not happy with it. Fine. But before
you called the fpc team being in a deadlock? Overcoming such deadlocks
does not make everybody happy.

>     As far as I remember, that was good feedback from developers like
> the idea of having
>     UnicodeString as UTF-16 on windows and under Linux, MacOSX, Unix
> etc it is UTF-8.
> 
>  * The above point would also alleviate the codepage compiler warning
> under Linux/Unix/MacOS when
>     delphiunicode mode (the only mode where String = UnicodeString).
> Then again ALL text files I have
>     even seen use UTF-8 as encoding, so even under Windows, source
> code should be assumed UTF-8
>     encoded. Java, C#, W3C (HTML & XML) etc all do that too.
> 
>   * Unicode & resource strings as Martin mentioned is not working yet.

Indeed, this can be fixed.

> 
> 
> There are lot of uncertanties, thus developers are reluctant to start
> using (and testing it), because they might end up having to change
> 100's of thousands of lines of code later again.
> 

Yes, this certanty is only given when we are at 2.8.0