Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2020-03

sizeof TTypeKind?

9 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Anthony Walter
to Sven Barth: What exactly do you want? TTypeKind is an enum, so there SizeOf(TTypeKind) is enough. Sven

I think what Ryan is asking about is how to find the size of the variant part of TTypeData as used in the "case TTypeKind of" section. As in:

      public
         {$ifdef PROVIDE_ATTR_TABLE}
         AttributeTable : PAttributeTable;
         {$endif}
         case TTypeKind of
            tkUnKnown,tkLString,tkWString,tkVariant,tkUString:
              ();
            tkAString:
              (CodePage: Word);
{$ifndef VER3_0}
            tkInt64,tkQWord,
{$endif VER3_0}
            tkInteger,tkChar,tkEnumeration,tkBool,tkWChar,tkSet:
              (OrdType : TOrdType;
               case TTypeKind of
...

Reply by email

Ryan Joseph
to Ryan Joseph: I'm going to loop through the fields of the record and get the size of each field so I…
On Mar 21, 2020, at 9:39 AM, Ryan Joseph via fpc-pascal wrote: I'm going to loop through the fields of the record and get the size of each field so I can serialize the record. Am I not on the right track?

No answers on this so I'm thinking maybe I need to use TManagedField^.FldOffset to get the information I need about the field size. Is that correct way to get the field size using record RTTI?

Regards,
Ryan Joseph

Reply by email

Ryan Joseph
to Anthony Walter: I think what Ryan is asking about is how to find the size of the variant part of…
On Mar 21, 2020, at 10:05 AM, Anthony Walter via fpc-pascal wrote: I think what Ryan is asking about is how to find the size of the variant part of TTypeData as used in the "case TTypeKind of" section. As in:

Yes. It says a field is "tkInteger" but what size is that? I know it's 4 bytes on my system put I don't want to make a lookup table since there's surely a better way to do this.

Regards,
Ryan Joseph

Reply by email

Sven Barth
to Ryan Joseph: No answers on this so I'm thinking maybe I need to use TManagedField^.FldOffset to get…
Ryan Joseph wrote 6 lines
> On Mar 21, 2020, at 9:39 AM, Ryan Joseph via fpc-pascal wrote: > > I'm going to loop through the fields of the record and get the size of each > field so I can serialize the record. Am I not on the right track? No answers on this so I'm thinking maybe I need to use TManagedField^.FldOffset to get the information I need about the field size. Is that correct way to get the field size using record RTTI?

For the primitve types you need to know the sizes at compile time (e.g. SizeOf(Word), SizeOf(LongInt), etc.) and check what type the field has using the field list in the record's RTTI. You also have to keep in mind that some types are grouped. E.g. tkInteger is for all integer types that are smaller than 64-bit. The real type is then available as TTypeData.OrdType and you need to handle that size accordingly. For structured types like records the size is contained in the RTTI. The FldOffset field is important to get the correct offset of a field, because padding might be involved depending on the platform (except if your record is "packed").

Regards,
Sven

Reply by email

Ryan Joseph
to Sven Barth
On Mar 21, 2020, at 10:15 PM, Sven Barth via fpc-pascal wrote: For the primitve types you need to know the sizes at compile time (e.g. SizeOf(Word), SizeOf(LongInt), etc.) and check what type the field has using the field list in the record's RTTI. You also have to keep in mind that some types are grouped. E.g. tkInteger is for all integer types that are smaller than 64-bit. The real type is then available as TTypeData.OrdType and you need to handle that size accordingly. For structured types like records the size is contained in the RTTI. The FldOffset field is important to get the correct offset of a field, because padding might be involved depending on the platform (except if your record is "packed").

ok, I guess I need to make a lookup table for tkInteger etc... or just take the field type names directly and map them myself.

Btw, I was thinking that the new custom attributes could be used to add RTTI to record fields but it appears to be limited to classes, and other class definitions. Is that correct?

Regards,
Ryan Joseph

Reply by email

Sven Barth
to Ryan Joseph

Ryan Joseph via fpc-pascal schrieb am
So., 22. März 2020, 07:28:

Show quoted text 19 lines
> On Mar 21, 2020, at 10:15 PM, Sven Barth via fpc-pascal < > wrote: > > For the primitve types you need to know the sizes at compile time (e.g. SizeOf(Word), SizeOf(LongInt), etc.) and check what type the field has using the field list in the record's RTTI. You also have to keep in mind that some types are grouped. E.g. tkInteger is for all integer types that are smaller than 64-bit. The real type is then available as TTypeData.OrdType and you need to handle that size accordingly. For structured types like records the size is contained in the RTTI. The FldOffset field is important to get the correct offset of a field, because padding might be involved depending on the platform (except if your record is "packed"). ok, I guess I need to make a lookup table for tkInteger etc... or just take the field type names directly and map them myself.

You don't need to do a lookup table for all types. Retrieve the PTypeData of the PTypeInfo (using GetTypeData) and check the OrdType if it's a tkInteger. Based on that you map the size.

Btw, I was thinking that the new custom attributes could be used to add RTTI to record fields but it appears to be limited to classes, and other class definitions. Is that correct?

For now that is correct as for everything else extended RTTI is required (though to be more precise attributes can be used for all type declarations, not only classes).

Regards,
Sven

Reply by email