Hello
Hello,
superobject do not compile anymore under Tokyo because of a change in TypInfo unit...and I don't understand the goal of that change.
in Berlin, TTypeData has a GUID:TGUID member for tkInterface
in Tokyo, the member has been replaced by IntfGuid : array[0..15] of Byte; with a inlined GUID function that make a copy of that record as a TGUID
There's probably a good reason for that, isn't it ?
superobject do not compile anymore under Tokyo because of a change in TypInfo unit...and I don't understand the goal of that change.
in Berlin, TTypeData has a GUID:TGUID member for tkInterface
in Tokyo, the member has been replaced by IntfGuid : array[0..15] of Byte; with a inlined GUID function that make a copy of that record as a TGUID
There's probably a good reason for that, isn't it ?
One less reference count, I guess?
ReplyDeleteLars Fosdal for what ? TGUID is a record, not an ARC type
ReplyDeleteno good reason, but perhaps in the mind of the RTL maintainer, which seems to be a bit confused here by introducing this change; anyway, EMB will answer to you that this TTypeData is too low-level, and subject to change whenever they want, even if it is not needed; this is why I ended up with defining my own RTTI types in mORMot, by-passing the TypInfo unit, but able to compile from Delphi 6 up to latest 10.2 (which evolved a lot during those years), and also with FPC (which has diverse low-level RTTI)
ReplyDelete> "no good reason", "the RTL maintainer... seems to be a bit confused"
ReplyDeleteWhoa, whoa. Hang on there.
I looked up the change and it was made to address an iOS and ARM issue with alignment. Looks valid to me. Other solutions might be padding etc but layout changes have carryon effects in the reader/writer and RTL. This was the smallest, least-impact change and therefore correct.
Please use the GUID method to access the GUID. You will also then be isolated from future changes.
David Millington Sorry for the FUD. But I wonder what alignment difference there is between a static array of 16 bytes and TGUID as a packed variable record containing only non managed ordinal values for a total of also 16 bytes. Both are just 16 bytes of memory. Or is there a limitation of the NextGen compiler with packed variable records, making it unable to properly align on 16 bytes boundaries as a function result?
ReplyDeleteNo worries! I don't have the answer there, sorry, I'm going on task tracker and commit messages, and I haven't manually calculated the field offset. I believe though it was an ARM architecture issue not the compiler itself per se.
ReplyDeleteIIRC, in such cases, the only problem about ARM alignment is if the block is not aligned on its native modulo (i.e. here aligned on 16 bytes). But it is mainly a performance problem, and the compiler should be able to do such alignment on stack, or - at least - generates slower asm to move the data byte per byte.
ReplyDeleteA. Bouchez and for the TypInfo structure is not a question of performance but of memory location...the compiler have to provide a way to define the structure the right way...and like you, I don't see any difference between the array and TGuid
ReplyDelete