Blog post "Key Traits of the Coming Delphi For Linux Compiler" at http://blog.marcocantu.com/blog/2017-february-delphi-linux-compiler.html
Blog post "Key Traits of the Coming Delphi For Linux Compiler" at http://blog.marcocantu.com/blog/2017-february-delphi-linux-compiler.html
http://blog.marcocantu.com/blog/2017-february-delphi-linux-compiler.html
http://blog.marcocantu.com/blog/2017-february-delphi-linux-compiler.html
For me, the most interesting piece of information is the "LLVM architecture". Will future versions of Delphi VCL have this option too?
ReplyDeleteSteve Maughan that has been on my wishlist for a very long time, especially the x86 target (which debugs way faster than the x64 target) so you can finally effectively debug ARC code on Windows.
ReplyDeleteDelphi Tokyo: Sorry, no business case for me.
ReplyDelete1. no gui.
2. vcl apps won't run on fmx framework. almost incompatible. there is no cross-vcl story.
3. fmx is very buggy. hobby level at the moment compared to vcl.
4. no complete 4k high dpi support in vcl and fmx. A pain in the ass for professional shops.
A lot more effort is needed in the GUI experience. e.g. Region support. advances paint engines, PDF support, etc. These are orphaned topics.
Steve Maughan, as in Marco's post: "The long term plan is to shift the entire Delphi ecosystem in that direction -- probably keeping the VCL world on the traditional memory model".
ReplyDeleteSo seems it will be supported for FM projects only!.
The ZBS madness was not entirely purged it seems, maybe next time?
ReplyDeleteRemoving AnsiString from UTF8String and RawByteString is the first sane choice in a long while.
Jeroen Wiert Pluimers part of the debugging trouble comes from LLVM, more than x86 vs x64 IIRC. LLVM is only reasonnably fast vs C compilers.
Et pour les francophones :
ReplyDeletelookinside.free.fr - Look Inside
/get-updates
ReplyDelete/sub
ReplyDeleteIt's wrong to claim that Windows memory model with long being 32 bit is non standard. Can anyone point to a standard that backs up that claim?
ReplyDeleteDavid Heffernan "non-standard" might not be the best description, given there isn't a standard. IN the C / C++ standard the size of long is platform specific. A better description could have been "off the mainstream" given all other notable platforms *nix and derivatives (Unix, Linux, macOS, iOS, Android) use the long = 64-bit appraoch
ReplyDeleteAbout ARC, it is not so tied to LLVM. We do ship a "traditional" compiler that is ARC enabled, the iOS simulator compiler.
ReplyDeleteDavid Heffernan I guess the context is the comparison of Unix and Windows here: stackoverflow.com - What is the bit size of long on 64-bit Windows?
ReplyDeleteWhile LP64 is the Unix convention, Windows went for LLP64.
Zero based strings are a total snafu. They need to disappear.
ReplyDeleteMarco Cantù
ReplyDelete> all other notable platforms *nix and derivatives (Unix, Linux, macOS, iOS, Android) use the long = 64-bit appraoch
A little imprecise. On those platforms, long is 32 bit on 32 bit machines, and 64 bits on 64 bit machines. The MS model has long as 32 bit everywhere, long long as 64 bit everywhere.
It's true that MS are the odd one out, but it's also true that their approach makes life easier for programmers.
Nowadays the C and C++ standards have fixed size types like int32_t, int64_t and so on. These also make life easier for programmers, generally a good thing in the eyes of this programmer.
Emba did everything right in my view when they introduced the 64 bit Windows compiler, all the types were mapped properly. I personally would have preferred the name IntPtr to NativeInt, so as to draw out the key point of the type being pointer sized.
And they also got it right with 64 long on non MS platforms, starting with iOS64. Emba were right to map LongInt to C++ long int and LongWord to C++ unsigned long int. These rules have long been established and you were right to follow them. It's just a little awkward for programmers. Stick to Integer, Cardinal, Int64 and UInt64 and it's all good!
Marco Cantù can't wait for WIndows to change to ARC(for non VCL) at some point to have the same memorymodel everywhere :)
ReplyDeleteCan you tell me by the way, why the decision was made that DisposeOf calls free, but not the other way around? I'd thought that free calls DisposeOf is the more intuitive way.
Alexander Benikowski Marco said:
ReplyDelete> The long term plan is to shift the entire Delphi ecosystem in that direction -- probably keeping the VCL world on the traditional memory model.
So, don't hold your breath. That means that the plan is that ARC will not come to Windows.
David Heffernan FMX on Windows is not VCL-World
ReplyDeleteAlexander Benikowski Would be kind of weird to have Windows compiler that could operate in both ARC and non ARC mode. What would happen to code that used both FMX and VCL, which I know is not supported.
ReplyDeleteDavid Heffernan the RTL and all the non visual part of the "CL" is used in both FMX and VCL :)
ReplyDeleteDavid Heffernan 'Emba were right to map LongInt to C++ long int and LongWord to C++ unsigned long int.' - Blimey, a proper guru makes an unambiguous defence of EMBT on the topic. Genuine question - can you expand on why was mapping to C/C++ platform types was a superior option to maintaining the traditional TP/Delphi definitions? (A Delphi Char remains not a C char, and a Delphi ShortInt remains not a C short.)
ReplyDeletequestion: does FMX on OSX , is that ARC?
ReplyDeleteGood info. Thanks Marco Cantù
ReplyDeleteBrian Hamilton No, that's not ARC
ReplyDeleteChris Rolliston Let us stick to integers first.
ReplyDeleteByte = unsigned char
Shortint = char
Word = unsigned short int
Smallint = short int
Cardinal = unsigned int
Integer = int
LongWord = unsigned long int
LongInt = long int
These mappings have been in place since Delphi 2 and are needed for, at least, Delphi and C++ Builder compatibility. Having put these mappings in place it feels natural to keep them in place.
What if programmers were expecting to interop with 64 bit Unix using LP64 model? It would be rum news for them.
As far as Delphi char, that's an alias and so outside of mapping rules. The raw types map as so:
AnsiChar = char
WideChar = wchar_t
David Heffernan 'LongInt' was just the TP/Delphi name for a 32 bit signed integer. This assumption is found in lots of places through the wider RTL, notwithstanding EMBT slowly cleaning this up after the iOS64 decision. From a purely Delphi-centric POV, if you want an alias for a C/C++ type, define an alias for it - CPPLong or whatever - and keep the traditional TP/Delphi naming unsullied.
ReplyDelete(That said, in an ideal world, I'd have a time machine and ensure the Int8/Int16/Int32/UInt8/etc. aliases were introduced back in Delphi 1, and moreover, as the intrinsic types not aliases to the intrinsic types.)