Maurice Lombardi wrote:
Frank Heckenbach wrote:
Prof Abimbola Olowofoyeku wrote:
On 19 Apr 2002 at 9:10, Adam Naumowicz wrote:
I found out that, unfortunately, the newest GPC has a changed processing of constructors. As far as I know, even the virtual methods should be identified in the compilation time in the sense, that when calling a constructor for an object (for example one with destroyed layout) the methods are called inside the constructor the static way.
That's not really what it did before. What I changed was to remove a (normally) redundant VMT pointer assignment. Usually the VMT pointer is assigned when the variable is created (i.e., at program/routine start for non-pointer objects, and after memory allocation when using `New').
Until recently, GPC *also* assigned the VMT when calling a constructor which is therefore redundant (especially when calling a constructor within `New', one could see two assignments next to each other which made it clear that one was redundant).
So you could have done the other way around, assigning the VMT pointer
only when calling a constructor. This would have given what Adam was expecting. Anyway an object is not valid until a constructor is called. Is there any drawback for that ?
Matter of taste probably ... If I declare `var MyObj: MyType' (i.e., not a pointer), I'd expect `TypeOf (MyObj)' (i.e., the VMT pointer) to have some reasonable value immediately.
Of course, that basically reduces constructors to almost regular methods with no special "magic" -- which I consider a good thing since any avoidable "magic" is only a source of confusion. Placing this magic at the point of creation of the objects seems more reasonable since that's where other kinds of initializations (schema discriminants, file variable default state, explicit initializers) are done.
Also, I don't see what we'd win the other way. It might perhaps work in Adam's special case, but in general, that's still bound to fail. If the object contains some fields of string, schema or file type (or in the future, types with explicit initializers), it still won't work with this FillChar/GetMem approach.
What I'm rather thinking of is a "magic" built-in procedure to initialize some given variable the same way it's initialized on creation. Yes, it's magic again (though it would require an explicit call, so it's not magic behind the scenes). And since it would do all the initializations (including discriminants and files, e.g.), it would be more consistent ...
Frank