Re: [sv-ec] virtual methods

Oh boy.  That's bad, but I've seen worse.

For both virtual and non-virtual methods I would state that an
override in some class C applies to a C and its descendants. However,
the behavior of virtual methods is best explained by what happens when
you *CALL* them.

First, we must differentiate between the type of a reference and the
type of object it refers to. e.g.:

class Base;
  function void foo(); endfunction
  function void bar(); endfunction
  virtual function void pow(); endfunction
endclass

class Derived extends Base;
  function void foo(); endfunction
  virtual function void bar(); endfunction
  virtual function void pow(); endfunction
endclass

class Leaf extends Derived;
  virtual function void pow(); endfunction
endclass

Leaf l = new;
Derived d = l;
Base b = d;

Here, "b" is of type Base. But it *refers* to an instance of type
Leaf.  For what follows, let "reference type" be the type of the
reference (Base) and "referee type" be the type of what the reference
points to (Leaf).

When a method (virtual or non-virtual) is called, then:
- Look at the virtualness of the method definition in the reference
type. If the method is not defined in the reference type then search
for a definition starting at reference type and working upward through
superclasses. Once you find a definition, use it only to determine
whether it is virtual and then follow the rules below.
- If the method is NOT virtual in the reference type, then search for
a definition starting at the reference type and working upward through
superclasses. The first definition found is the function that will be
called.
- If the method IS virtual, then search for a definition starting at
the REFEREE TYPE and working upward through superclasses. The first
definition found is the function that will be called.

Examples:

b->foo(); // foo() is not virtual in reference type (Base). Therefore
first definition is Base::foo()
d->foo(); // ditto. Here we must look up to pick up the definition in Base.
l->foo(); // ditto.
b->bar(); // bar() is not virtual in reference type (Base). Therefore
Base::bar() is called. NOTE: bar() is virtual in a derived type. This
does not matter.
d->bar(); // bar() IS virtual in reference type (Derived). Therefore
we start looking for a definition in Leaf. But there is no definition
of Leaf::bar() so we drop back to Derived::bar(). Had there been a
definition of Leaf::bar() we would call that.
l->bar(); // Derived::bar() is inherited by Leaf, so Derived::bar() is called.
b->pow(); // pow() is virtual in Base, so start looking at referee
type (Leaf). We find Leaf::pow().
d->pow(); // ditto.
l->pow(); // ditto.

This example may seen long-winded, but I hope I've covered all of the cases.

Final note: these rules apply only to "naked" method calls of the form
ref.method(). A call of the form super.method() is never a virtual
call (even if the method is defined as virtual). A typical use is when
you want to add functionality to method without wanting to replace it
entirely:

function void Derived::bar();
  super.bar(); // never a virtual call otherwise we'd endlessly
recurse and blow our stack
  // now do additional work
endfunction



On Wed, Dec 31, 2008 at 8:50 AM, Bresticker, Shalom
<shalom.bresticker@intel.com> wrote:
> Hi,
>
> 8.19 says,
>
> "A virtual method shall override a method in all of its base classes,
> whereas a non-virtual method shall only override a method in that class and
> its descendants. One way to view this is that there is only one
> implementation of a virtual method per class hierarchy, and it is always the
> one in the latest derived class."
>
> This text is unclear to me. Can someone explain what it is intended to mean?
>
> Thanks,
> Shalm
>
> Shalom Bresticker
> Intel Jerusalem LAD DA
> +972 2 589-6582
> +972 54 721-1033
>
>
>
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> This email was Anti Virus checked by Astaro Security Gateway.
> http://www.astaro.com
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.