Well, it proves my old decision not to bother with Delphi for the 101st time.
I was taking for granted any modern language would be smart enough to replace VMT pointers or do whatever else is required during the time of the object's creation or destruction to prevent the possibility of calling a function that potentially deals with those members which are yet to be created or have already been destroyed. Obviously, I was wrong :)
By the way, is it possible in Delphi to call its descendant's functions from a constructor of the parent class? If so, it makes no sense, either. Otherwise, it's inconsistent at very least.
As to the calling of abstract methods, C++ obviously doesn't allow doing that - however, I do experience a "pure virtual function call" message every time my SourceSafe client crashes. Don't ask me how Microsoft does that :) However, other than having the instruction pointer get to the pure virtual function definition as a result of an illegal workflow, I hardly think of any other possibility of calling it.
"pure virtual function call" has nothing to do with calling abstract methods, it just a NULL pointer dereferenced to a derived class with virtual methods.
It all depends on how effective the language needs to implement the polymorphism. Obviously, the VMT is more effective (although less flexible) than the reflection or any other RTTI-based/alternative mechanism.
As for the "nothing to do"... The "pure virtual function call" message is nothing more but the code of a stub all the non-implemented methods point to (or, as an alternative, a handler for the exception that is raised in case the instruction pointer has to proceed with the NULL address) - and this message is exactly what would pop up in case an abstract method was called.
(no subject)
Date: 2003-12-24 08:10 am (UTC)I was taking for granted any modern language would be smart enough to replace VMT pointers or do whatever else is required during the time of the object's creation or destruction to prevent the possibility of calling a function that potentially deals with those members which are yet to be created or have already been destroyed. Obviously, I was wrong :)
By the way, is it possible in Delphi to call its descendant's functions from a constructor of the parent class? If so, it makes no sense, either. Otherwise, it's inconsistent at very least.
As to the calling of abstract methods, C++ obviously doesn't allow doing that - however, I do experience a "pure virtual function call" message every time my SourceSafe client crashes. Don't ask me how Microsoft does that :) However, other than having the instruction pointer get to the pure virtual function definition as a result of an illegal workflow, I hardly think of any other possibility of calling it.
(no subject)
Date: 2003-12-24 10:30 am (UTC)"pure virtual function call" has nothing to do with calling abstract methods, it just a NULL pointer dereferenced to a derived class with virtual methods.
(no subject)
Date: 2003-12-24 11:24 am (UTC)As for the "nothing to do"... The "pure virtual function call" message is nothing more but the code of a stub all the non-implemented methods point to (or, as an alternative, a handler for the exception that is raised in case the instruction pointer has to proceed with the NULL address) - and this message is exactly what would pop up in case an abstract method was called.