I am studying OOP languages at uni and we've discussed a lot on virtual destructors using C++ as example. I've a doubt regard Delphi by the way. Let's say that we have ClassA and ClassB (which is a subclass of ClassA). So in this C++ code:
I am studying OOP languages at uni and we've discussed a lot on virtual destructors using C++ as example. I've a doubt regard Delphi by the way. Let's say that we have ClassA and ClassB (which is a subclass of ClassA). So in this C++ code:
ClassA* x = new ClassB;
delete x;
I have to declare the destructor of ClassA virtual so I do a proper delete clean-up of the memory. I have to use virtual destructors when a class behaves polimorphically like above. In Delphi I can do:
x := ClassB.Create; //where of course x: ClassA;
x.Free;
I have seen that TObject's destructor is virtual so in every delphi class we have to OVERRIDE the destructor. So my questions are:
1) In Delphi are ALL destructors virtual by default? Every delphi class inherits from TObject, TOjbect has a virtual destructor so every destructor in the children classes must be overridden since it is virtual as well.
2) In c++ I can make pure virtual destructors ( like ~ClassA() = 0; ). Does it make sense in Delphi as well having destructor Destroy; virtual; abstract; ?
ClassA* x = new ClassB;
delete x;
I have to declare the destructor of ClassA virtual so I do a proper delete clean-up of the memory. I have to use virtual destructors when a class behaves polimorphically like above. In Delphi I can do:
x := ClassB.Create; //where of course x: ClassA;
x.Free;
I have seen that TObject's destructor is virtual so in every delphi class we have to OVERRIDE the destructor. So my questions are:
1) In Delphi are ALL destructors virtual by default? Every delphi class inherits from TObject, TOjbect has a virtual destructor so every destructor in the children classes must be overridden since it is virtual as well.
2) In c++ I can make pure virtual destructors ( like ~ClassA() = 0; ). Does it make sense in Delphi as well having destructor Destroy; virtual; abstract; ?
Dalija Prasnikar Sure I have done that, but UI frameworks are one if the few examples where deep inheritance structures are appropriate. And I don't recall ever needed to subvert the ordering of calls to inherited ctor. Do you have an example?
ReplyDeleteI find it amusing to hear people justify these practices.
David Heffernan Actually, I have... but I could not reproduce the behavior yesterday... so either something has changed in VCL in the meantime or I didn't try my code to full extent (it is a bit complicated scenario)
ReplyDeleteI have extended VCL styles to support skinning per control. That requires additions to both control itself and control style hook. In order to connect everything properly, I had to create control skin engine before inherited constructor is called, and release it after inherited destroy.
I know there was a reason for specific ordering because I put comment in my code about order, but unfortunately, I didn't write full explanation about why :)
Raffaele Miola Was this useful, even if the discussion went off course?
ReplyDelete