On Sat, 4 May 2024, Tony Whyman via fpc-pascal wrote:
Michael,
I believe that the diplomatic answer to your response is that it is
"disappointing". This is a serious problem and needs to be discussed.
Thank you for being diplomatic.
Interfaces between modules written in different programming languages or
even built with different compilers are never easy and depend on having
published and stable definitions for each data type and structure. This
is a common problem for anyone using Pascal given how so many code
libraries are written 'C' or C++. Change can imply breaking many user
programs and should not be done lightly and for purely internal reasons.
We guarantee backwards compatibility (as much as possible) on the language
level and API level, but not on the internal structure of objects.
The only structure that is guaranteed to work with C or C++ is the record.
Hence my proposed solution using a record.
Both object and class type data structures are published in the Free
Pascal Documentation
You may wish to re-read the documentation and specifically this:
https://www.freepascal.org/docs-html/current/ref/refsu23.html#x73-970006.3.1
'As of version 3.0 of the compiler, the compiler can re-order the fields in memory
if this leads to better alignment and smaller instances. That means that in an instance,
the fields do not necessarily appear in the same order as in the declaration.'
So your vTable also is in no way guaranteed to be correct, the above
explicitly says that your assumptions are invalid.
In the case of monitor data, you have said that Delphi have implemented
this as a "hidden" field. I presume that you mean that this uses a
technique such as a negative offset to the object instance pointer.
No, actually behind all other fields.
I don't intend to do work on this, since nowhere was there any guarantee
that TObject has no fields. As I wrote, this assumption has no basis and
this is even documented. It works purely by chance, not through design.
I have given you a possible way to fix it, which is IMO the only correct and
future proof way to implement what you need.
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal