On Sat, 12 Sep 2009, Jonas Maebe wrote:
On 12 Sep 2009, at 15:10, Paul Ishenin wrote:
Paul Ishenin wrote:
Just tested with D2009:
TStdcallMethod = procedure(Sender: TObject; Something: LongInt) of object;
stdcall;
If it is stdcall then methods must be listed in the rtti right-to-left but
delphi stored Sender as first and Something as second.
To prove my founds I just wrote a small test application which compiles on
D7, D2009, D2010 and FPC.
I've checked it with Kylix 3 and there it's indeed also always the same
order. Apparently I made a mistake while testing. The FPC logic of storing
the parameters in the rtti in the same order as the calling convention uses
them dates from before my changes though. I'm not aware of any functionality
in FPC or the RTL depending on this order, so it shouldn't be a problem to
change it. Then again, I know almost nothing about any functionality using
RTTI (other than reference counting), so I'll wait with changing anything to
see whether someone else maybe knows a reason why this should not be changed.
As far as I know, the RTTI should store the information in the order that
the parameters appear in the declaration. It should not depend in any way
on the actual calling convention. This is sufficient to create a declaration for
an event handler.
But if it should be possible to decide on the basis of RTTI solely, whether a
declared procedural property matches a published procedure on the ABI level,
that would mean that the calling convention should also be available through
RTTI, and so a field must be added to the RTTI, with a calling convention specifier.
So, in my opinion:
a) Put parameters in declared order.
b) Add (after result type name) a field with the calling convention.
That would help, BTW, to implement dispatch interfaces based on RTTI.
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
