What OO do you have left then? Records can contain methods.
TP objects only allocate a VMT when virtual methods are defined.
I'm not sure using getmen and freemem handle fields with automated types. You would have to add initialize and finalize calls for that.
What OO do you have left then? Records can contain methods.
As I wrote, I don't need methods and properties — simple fields only.
I use objects instead of records because objects support inheritance and records do not.
But any kind of polymorphism will be hard.
The problem is that you are asking something that is undocumented. […] FPC has a few hundred thousand lines of code, a quick search for the corresponding type tobjectdef shows over 1000 occurrences in the code. So making a definite claim is not really easy.
At least from the documentation I can tell you that ABI stability is not a design criterium of objects and as such even if it may be the case now there is no guarantee it will stay this way
It's a pity that standard records don't support protected content. Of course, the point is not to have their own VMT, but to make the content of records visible only in the module of their declaration and in modules with declarations of records inheriting from them. If that were the case, I would use regular records to achieve sensible encapsulation of simple data structures, and not bother with TP objects.huh ? afaik that mechanism is in place with advanced records, e.g. private/public parts. Or is that not what you meant ?
So, so far, I haven't found any evidence that a TP object containing only fields is not binary compatible with records.Be very careful making any assumptions.
Indeed better rely on one of the core developers to provide a more clear answer.
Even if things look like something it is not guaranteed to be the same in the (near) future).
I eventually solved that by using a managed record that contained a class (it was the quickest (and dirtiest) solution at the time).
Objects are stored in memory just as ordinary records with an extra field: a pointer to the Virtual Method Table (VMT). This field is stored first, and all fields in the object are stored in the order they are declared (with possible alignment of field addresses, unless the object was declared as being packed).https://www.freepascal.org/docs-html/prog/progsu165.html
However, none mentions the possible reordering of fields with optimization. Maybe it is in another place.
So the record documentation is really clear that the layout is very well defined, including alignment, etc. There is nothing comparable in the documentation for classes and objects
Since objects and classes, as the documentation said, are ordinary records (with an additional field for a pointer to the VMT), there is no point in describing it — those interested can simply go to the documentation of records and learn the memory layout there.But it's not, besides field reordering have classes different alignment rules (emg. They are not influenced by packrecords directive). So I just know from the top of my head two differences between records and classes, I would bet there will be more. I would not take that single sentence from the documentation as normative, it's the introductory sentence to describe the concept of classes, not to be interpreted to literally
However, if you think that the documentation is not up to date, it is a good idea to ask the developers to confirm this.
QuoteI'm not sure using getmen and freemem handle fields with automated types. You would have to add initialize and finalize calls for that.
This is not a problem, because I always declare an initialization and finalization function, as well as an allocating and deallocating function for each record and object. This way I can freely use such data structures and allocate them on both the stack and the heap, regardless of whether they contain fields that require initialization/finalization.
The lack of information about packing these data structures in the documentation is a minor inconvenience, but the compiler works according to what is in the documentation - objects and classes are ordinary records, so you can influence their memory layout with a directive intended for records.
Unless your initialization functions also contain calls to FPC's System.Initialize() intrinsic then this is a very dangerous […]
And your finalization functions not using System.Finalize will lead to memory leaks, because FreeMem alone will not clear memory of managed types.
Since I don't use data types that needs to be silently initialized and finalized by the compiler, I don't have to use System.Initialize and System.Finalize.
However, from what I've researched, even if I were to use managed-typed fields, I still wouldn't need to use System.Initialize and System.Finalize, since in the object initialization function I set the default values for all fields myself, and in the finalization function I free the resources that were allocated during the object initialization and/or use.