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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
