[fpc-devel] Patch #31249 and objects

[Sven Barth]

On 31.01.2017 18:45, Maciej Izak wrote:
> 2017-01-31 14:56 GMT+01:00 Sven Barth <pascaldragon at googlemail.com
> <mailto:pascaldragon at googlemail.com>>:
> 
>     I "ignored" it, cause up to now it was merely a performance
>     improvement. If you had added your info from 31305 to 31249 instead
>     of creating a new report then I might have reacted faster.
> 
> Very sad info. 31305 costed me additional time. 31305 is separate
> problem so has separate ticket. I didn't knew about 31305 until today.

I've applied the patch now (with adjustments to the changes that had
happened in trunk).

A little sidenote: the "day unique" part of an internal error is
supposed to be two digits and to start from 1, so your internal error
should have been 2017011801 instead of 201701180 (I've corrected that
already).

>     Anyway, I'll try to get it applied tonight.
> 
>     PS: If you adjust mORMot then I highly suggest you not to use custom
>     records/objects, but the typinfo ones as much as possible as they
>     deal with alignment issues correctly (especially the new types of
>     the interface RTTI). Or at least use the typinfo types to retrieve
>     pointers to the correct parts of the RTTI and store those instead of
>     using inc()s to navigate the RTTI.
> 
> Not that simple, almost impossible to use only TypInfo. mORMot has
> support for very large range of compilers: FPC >= 2.6.4  and Delphi >=
> 5... Custom records/objects are often the only way to keep sensible code
> base... mORMot has own aligntoptr implementation (which is different for
> each compiler and platform if needed). aligntoptr is used together
> with inc()s. TypInfo is generally incompatible in many ways between
> Delphi and FPC so we have a lot of $IFDEFs for low level RTL / RTTI and
> own structures. 

I still can't recommend the way it's done in mORMot. This will break
each time the binary format of the RTTI changes. Take my adjustment of
TProcedureParam.Flags (now .ParamFlags) for example which I changed from
Byte to TParamFlags which not much later changed its size from Byte to
Word due to newly added elements. You might not catch such a change
especially if it should be used in a seldomly used code branch.

My suggestion would be an RTTI abstraction that makes use of inline
methods/properties  as part of objects/records to access the Delphi and
FPC RTTI.

For example another change that will come up in the near future will be
a link from the TTypeData to the unit its contained in which will again
lead to a shift in fields.

Regards,
Sven