Mattias Gaertner wrote:
> "George Birbilis" <[EMAIL PROTECTED]> wrote:
> > X.Free
> > Should never fail since it's a class method and its implementation
> > checks if X is nil.
>
> It's not a class method. It's a normal method. IMO this has been confused
> several times in this thread. A class method has the 'class' keyword in
> front of it.
type
TA = class
class procedure Fn;
procedure Foo;
procedure Bar; virtual;
end;
class procedure Fn;
begin
self.fn; // recursively calls itself like a normal function
end;
procedure Foo;
begin
self.Foo; // may fail if self is undefined
end;
procedure Bar;
begin
self.Bar; // always succeeds, as an invalid self would
// have been trapped by the calling routine
end;
The difference between a class method and a non-virtual method, is that a
non-virtual method has the ability to access a possibly invalid self. And
that's what makes it so dangerous.
Bram Kuijvenhoven wrote:
> Michael Van Canneyt wrote:
> >> If so, what side-effects would this cause when applied across the
> >> complete class-hierarchy?
> >
> > Blow up the size of you executable.
>
> And a virtual method call is slower than a non-virtual call. (as it needs
> to do a few lookups: class, VMT)
>
> To ensure self is not nil, you can insert a check in a method itself.
> However, you cannot defend yourself against an invalid (but non-nil)
> object pointer. (I.e. a pointer to an object that is freed already.)
Is there a switch to pass to FPC to get a virtual method effect on
non-virtual methods, without incurring the VMT overhead?
Thanks!
--
Al
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
