Re: [fpc-devel] Improved RTTI compromise

Am 07.12.2016 11:31 schrieb "Maciej Izak" : >> Okay then, maybe I'll manage that this week (no promise though ;) ). >> I personally think that removing TRttiContext for now is the better >> choice, so people will know not to use it while they might expect valid >> values in the

Re: [fpc-devel] Improved RTTI compromise

On 07.12.2016 16:16, Jonas Maebe wrote: > On 07/12/16 14:38, Sven Barth wrote: >> But aside from that you could indeed already start to implement >> Invoke(), maybe based on the mORMot code. > > That code is also in fpc/branches/interfacertti. But as mentioned in > earlier threads about this, I

Re: [fpc-devel] Improved RTTI compromise

2016-12-06 23:39 GMT+01:00 Sven Barth : > 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

Re: [fpc-devel] Improved RTTI compromise

2016-12-07 8:49 GMT+01:00 Michael Van Canneyt : > > I am not sure this is possible. The structures exposed in the typinfo > interfacee mimic the info the compiler generates in the binary. > > If the compiler generates different info than Delphi, you cannot retrieve > it in

Re: [fpc-devel] Improved RTTI compromise

Don't forget that there is some working code of interface "Invoke" and "fake" in mORMot.pas: - working with FPC_HAS_EXTENDEDINTERFACERTTI or manual-registered RTTI, - x86 and x64 support on Windows and Linux ABI - ARM 32-bit and 64-bit (preliminary) support - well tested under Windows, good

Re: [fpc-devel] Improved RTTI compromise

On Wed, 7 Dec 2016, Sven Barth wrote: Trying to generate the exact same information as Delphi is IMHO not the right path. What is needed is an API that gives you the info contained in the internal structures. That's what the RTTI unit is there for. It provides a higher level API to the

Re: [fpc-devel] Improved RTTI compromise

Am 07.12.2016 11:31 schrieb "Maciej Izak" : > > 2016-12-06 23:39 GMT+01:00 Sven Barth : >> >> 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

Re: [fpc-devel] Improved RTTI compromise

Am 07.12.2016 13:58 schrieb "Michael Van Canneyt" : > > > > On Wed, 7 Dec 2016, Sven Barth wrote: > >>> Trying to generate the exact same information as Delphi is IMHO not the >> >> right path. >>> >>> >>> What is needed is an API that gives you the info contained in the >>

Re: [fpc-devel] Improved RTTI compromise

On Wed, 7 Dec 2016, Michael Van Canneyt wrote: On Wed, 7 Dec 2016, Sven Barth wrote: Trying to generate the exact same information as Delphi is IMHO not the right path. What is needed is an API that gives you the info contained in the internal structures. That's what the RTTI unit is

Re: [fpc-devel] Improved RTTI compromise

2016-12-07 9:45 GMT+01:00 Arnaud Bouchez : > Don't forget that there is some working code of interface "Invoke" and > "fake" in mORMot.pas: > - working with FPC_HAS_EXTENDEDINTERFACERTTI or manual-registered RTTI, > - x86 and x64 support on Windows and Linux ABI > - ARM

Re: [fpc-devel] Improved RTTI compromise

On Wed, 7 Dec 2016, Sven Barth wrote: Am 07.12.2016 13:58 schrieb "Michael Van Canneyt" : On Wed, 7 Dec 2016, Sven Barth wrote: Trying to generate the exact same information as Delphi is IMHO not the right path. What is needed is an API that gives you the

Re: [fpc-devel] Improved RTTI compromise

On Wed, 7 Dec 2016, Maciej Izak wrote: 2016-12-07 8:49 GMT+01:00 Michael Van Canneyt : I am not sure this is possible. The structures exposed in the typinfo interfacee mimic the info the compiler generates in the binary. If the compiler generates different info than

Re: [fpc-devel] Improved RTTI compromise

On 07/12/16 14:38, Sven Barth wrote: But aside from that you could indeed already start to implement Invoke(), maybe based on the mORMot code. That code is also in fpc/branches/interfacertti. But as mentioned in earlier threads about this, I think it should be generalised in a way that does