[fpc-devel] bug report 20473: Please add a directive to define string=utf8string

[Craig Peterson]

On 10/13/2011 2:03 PM, Marco van de Voort wrote:
> No backwards compatibility, no native ties to tie it down. Clearly it is
> meant to be fast moving by skipping details. And that doesn't appeal to the
> bulk of the Delphi crowd

They're so far behind they pretty much have to run fast and loose.

I'm certainly not advocating it myself.  I think it's a buggy mess, and 
wouldn't use it for a desktop app until it does a better job of acting 
native, but I do expect a lot of developers to transition to it 
eventually.  If they don't, Delphi doesn't have a strong future anyway.

> That is however fully true, revenue growth won't come from the traditional
> Delphi/VCL users, it will only wane.  But that is something totally, totally
> else than killing off VCL and trying to convince them to go to FM.

They aren't killing the VCL off, but it is mature, so it doesn't need as 
many resources.  It now supports Unicode and Win64, and can't support OS 
X/iOS/Android/Metro.  I'm sure the new styling engine needs work, and 
there's plenty of other fixes, but I have a hard time seeing what other 
extensive development they could do with it.  About the only other 
missing feature is fast, scalable vector graphics, and that's FireMonkey.

> I don't understand this. Yes the ansistring system uses 1252, but the
> compiler/RTL can make the mappings, so I don't really understand your
> problem.
>
> A numeric enumeration of codepages is more efficient (and less free form)
> than a stringbased one, so the Windows system isn't that bad.

I wasn't commenting on using integers vs. strings to represent the codepage.

Whenever you pass a PAnsiChar string to a system function (eg, lstat on 
Unix, CreateFileA on Windows), the system expects a specific encoding. 
On Windows that encoding is one of the "ANSI" encodings like 
"Windows-1252".  On OS X it's UTF-8.  On Linux it's the "LC_CTYPE" 
encoding, usually either UTF-8 or one of the ISO encodings like "ISO 
8859-1".

In FreePascal (currently), Kylix, and Delphi 2007 and earlier, that 
encoding was represented by the CP_ACP encoding, and the AnsiString 
type, so any AnsiString<->WideString conversions use it.

In Delphi XE2 on OS X AnsiString does *not* map to UTF-8.  On an English 
system it maps to "Windows-1252".  If you want to convert an "array of 
AnsiChar" to a WideString you need to cast it as a UTF8String first.  By 
default DefaultSystemCodePage is 1252, not 65001.

-- 
Craig Peterson
Scooter Software