[fpc-devel] Improved RTTI compromise
pascaldragon at googlemail.com
Wed Dec 7 14:38:40 CET 2016
Am 07.12.2016 11:31 schrieb "Maciej Izak" <hnb.code at gmail.com>:
> 2016-12-06 23:39 GMT+01:00 Sven Barth <pascaldragon at googlemail.com>:
>> Most Delphi code probably uses the RTTI unit anyway for this. And when
>> playing with the RTTI one needs to keep track of FPC vs. Delphi anyway
>> cause we'll never be 100% compatible (e.g. the Interface RTTI branch
>> does not keep in mind parameters that might be split across multiple
>> locations (like two registers), so that needs to be extended compared to
> 100% agree I don't have problem with a little Delphi incompatible RTTI,
the bigger picture is more important than small details, but quote from
Jonas Maebe ([fpc-devel] Attributes
> thread): "some people wanted it to be Delphi compatible, other people
did not mind if it was not. Both categories of people were in the core
I personally am among those who don't need Delphi compatibility ;)
>> However I think that we'll add the Delphi compatible TAttrEntry, but
>> with an additonal AttrCreate field before the AttrCtor field. The former
>> will then contain a pointer to the generated "fast invoke" function
>> while AttrCtor, ArgLen and ArgData will be Delphi compatible.
> mostly redundant info, but probably best what we can get.
For now we could leave out the AttrCtor, ArgLen and ArgData fields and only
add them if someone really needs them...
>> I don't know whether an early implementation of Invoke() would be a good
>> idea already as it would need a heavy rewrite once parameter location
>> support is available in the RTTI...
> what you mean by "heavy rewrite once parameter location"? Invoke is
extremely usefully even without detailed RTTI info about parameters, for
example for scripting purposes. I don't mean only pascal functions, script
is able to call external system API. Very handy.
Just checked the declaration of Invoke() and my statement was based on a
wrong memory of mine as I had forgotten that it merely takes the calling
convention and not the parameter locations. Though it might he necessary to
add an Invoke() overload that also takes the parameter locations as this
way we'd be able to use Invoke() also with the Amiga syscall functions as
there the registers to use are specified as part of the functions
But aside from that you could indeed already start to implement Invoke(),
maybe based on the mORMot code.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fpc-devel