On 18/02/2026 10:34, Tony Whyman via fpc-pascal wrote:
Supplementing my point below, I went back and checked my notes. The TObject layout post 3.2 (in my copy of trunk) is nowTObject = class {$IFDEF SYSTEM_HAS_FEATURE_MONITOR} strict private _MonitorData : Pointer; privatefunction SetMonitorData(aData,aCheckOld : Pointer) : Pointer; inline;function GetMonitorData: Pointer; inline; {$ENDIF} protected function GetDisposed : Boolean; inline; Property Disposed : Boolean Read GetDisposed; publicwith everything before "public" having been added. The big change is the addition of "_MonitorData". This bumps the offset of all later fields up by sizeof(pointer). If you have code that makes assumptions about the object layout - and this very much applies to code that tries to import an object from C++ then your previous assumptions are invalid.
Pfew.. when you initially wrote your "observations" I didn't realize this issue. In our product, based on old delphi code, an object is used as "record with methods" to interface with various IP based systems. The methods are used for dissecting packets, endianes conversions, bit fiddling, flag handling etc.
As long as no virtuals were used, an object hadn't any memory overhead.
The advice I got was that for external interfaces, only the "record" layout is immutable between versions. In the end, I had to remove all the Firebird interface code that relied on the assumption that the Pascal object layout was the same as the C++ and replaced it with extended records in order to mimimise the impact on code that used the API.
In our case advanced records are not an option since a large part of the codebase is still used by that old delphi.
That will mean that we need to stick to 3.2 Thanks for warning. Marc _______________________________________________ fpc-pascal maillist - [email protected] https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
