RE: [sv-ec] Query related to virtual methods in a class

Don,

 

My comments below.

 

            Arturo

 

________________________________

From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Don
Mills
Sent: Friday, October 20, 2006 7:49 AM
To: sv-ec@eda.org
Subject: Re: [sv-ec] Query related to virtual methods in a class

 

Arturo, 

Your replay is a little confusing to me...

Arturo Salz wrote: 

Don,

 

...



 

First you note that "an extended class is not required to override a
virtual method



As for your question. An extended class is not required to override (or
re-implement) a virtual method introduced by any of its ancestors.

Then you state that if the parent class is virtual with a virtual
method, the exended class must provide an implementation for that
virtual method.for the class to be come concrete.



[Arturo] I hope those two statements are not confusing. They are
certainly not contradictory. What that means is:

1.       Objects may only be created from concrete classes.

2.       Abstract classes may contain un-implemented virtual methods
(i.e., pure virtual methods).

3.       An abstract class may be extended into either an abstract class
or a concrete class.

4.       A Concrete class may be extended into either an abstract class
or a concrete class.

5.       Users may define a concrete class (one in which all its methods
are implemented) as virtual thereby disallowing the creation of objects
of that class.

6.       Virtual methods are inherited - just like regular methods.
Hence, a virtual method implemented in some super class A shall be the
method called unless a derived class overrides the virtual method with a
different implementation.

 

If the parent class is virtual (i.e., abstract) and the virtual method
is undefined then the extended class must provide an implementation for
the virtual method in order for the class to become concrete - and be
able to create objects of that class. If, on the other hand, the parent
class is not virtual and does provide an implementation of the virtual
method then the extended class does not need to override the virtual
method; it will simply inherit the virtual method implemented by its
closest ancestor. Perhaps, if you provide an example we can identify the
exact problem you are seeing.

 

            Arturo

So,  as I understand this, implementing virtual methods in extended
classes are optional.  Of course, if they are implemented, they must
follow the prototype declared in the base class.

Using (and modifying code from Gord's email) to elaborate 


module top;
  virtual class base;
    virtual task t;
    endtask // t
    
    virtual task t2;
      $display("in base::t2");
    endtask // t2
    
    virtual task t3;
      $display("in base::t3");
    endtask // t3
  endclass
  
  virtual class mid1 extends base;
    task t;
      $display("in mid1::t");
    endtask // t
  endclass
  
  class mid2 extends base;
    task t2;
      $display("in mid2::t2");
    endtask // t2
  endclass
  
  class mid3 extends base;
  endclass // mid3

  class bot extends mid1;
  endclass // bot
  
  
//  mid1 m1 = new;
  mid2 m2 = new;
  mid3 m3 = new;
  bot  b  = new;
  
  initial begin
//    m1.t;  // prints:    in mid1:t
//    m1.t2;  // prints:     in base:t2 
    
    $display("entering mid2");
    m2.t;
    m2.t2;
    m2.t3;
    $display("leaving mid2");
    $display;

    $display("entering mid3");
    m3.t;
    m3.t2;
    m3.t3;
    $display("leavinging mid3");
    $display;

    $display("entering bot");
    b.t;
    b.t2;
    b.t3;
    $display("leavinging bot");
  end
endmodule


The results from simulating the code above:
# entering mid2
# in mid2::t2
# in base::t3
# leaving mid2
# 
# entering mid3
# in base::t2
# in base::t3
# leavinging mid3
# 
# entering bot
# in mid1::t
# in base::t2
# in base::t3
# leavinging bot


My conclusions are, none of the extended classes mid1, mid2, mid3 are
required to included and define the virtual task declared in virtual
base classes. 



[Arturo] Unfortunately, your conclusion depends on the interpretation of
your example, which touches on an ambiguity in the LRM that is addressed
by the introduction of "pure virtual" method declarations. Specifically,
consider the base class declaration:

virtual class base;

    virtual task t;

    endtask // t

            ...

endclass
Does task t represent an un-implemented task (i.e. just a prototype)? Or
is it an implementation of a method that does nothing? The answer is
that the compiler cannot tell the difference, and that may or may not
have been your intent. The introduction pf "pure virtual" methods makes
the answer explicit - Task t is an implementation of virtual method t,
hence none of the derived classes mid1, mid2 or mid3 are required to
implement method t in order for them to be concrete classes. Note that
if you had defined base::t to be "pure virtual" then classes mid2 and
mid3 would be illegal because they provide no implementation for task t,
and the classes are not defined as virtual (i.e., abstract).


The reason I am asking all this is due to a sentence in section 7.19:
"In general, if an abstract class has any virtual methods, all of the
methods must be overridden (and provided with a method body) for the
subclass to be instantiated."

This implies to me that the virtual methods must be defined in the
extended classes.  Ummm, that is not what I am seeing from simulation.



[Arturo] I can see why that sentence is confusing. What it should say is
something along this:

A class that has any unimplemented virtual methods shall be defined as a
virtual class. Objects of virtual classes may not be created. In order
for an abstract class to be extended into a non-abstract (concrete)
class, no virtual method shall remain un-implemented in the extended
class. To provide an implementation for a virtual method, an extended
class shall override the method and provide an implementation (a method
body).

Note that the last sentence can now be reduced to "... override the
method by a non pure virtual method"

 


(Note that I did not make any of the task "pure".)


 



-- 
==========================================================
Don Mills
LCDM Engineering     (Logic, Coding, & Design Methodology) 
mills@lcdm-eng.com                        www.lcdm-eng.com
801-282-6560  Office PHONE      
801-641-5882  Mobile PHONE
4158 W. Ben Armine Cir.,      South Jordan, UT  84095-9101
==========================================================