RE: [sv-ec] Follow-up from last call -- legality of virtual/pure virtual overrides

Given the code below, what would you expect the behavior to be?

initial begin
  c c_i;
  e e_i;
  e_i = new();
  c_i = e_i;
  c_i.f(); // Does this call c::f() or e::f()?
end

Given the behavior you expect below, if the above code would call c::f(), then there'd be no reason to expect d::f() to prototype a valid override of c::f(). If the above would call e::f(), then d::f() must have a valid override of c::f().

If the code below is legal, then the behavior above needs to be clarified.

-Brandon

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Daniel Mlynek
Sent: Sunday, June 26, 2011 11:57 PM
To: neil.korpusik@oracle.com
Cc: Gordon Vreugdenhil; SV_EC List
Subject: Re: [sv-ec] Follow-up from last call -- legality of virtual/pure virtual overrides

I can see a situation when smbd want to discard the implementation of a
base class method in his class - so when extending his class new body of
method need to be given.
I do not see reason to block below code (it can be implemented, it has
reasonable interpretation)

     class c;
         virtual function void f(int a=0);$display("%m"); endfunction
      endclass
      virtual class d extends c;//virtual here is a must
         pure virtual function void f(int a=0);
      endclass
      class e extends d;
         virtual function void f(int a=0);
             $display("%m");
             //super.f; //calling super f is illegal here as it has no
implementation
         endfunction
      endclass

DANiel

On 6/25/2011 12:55 AM, Neil Korpusik wrote:
> It is my understanding that pure virtual methods are only allowed within
> an abstract base class. That would make class d in your example illegal.
> function f in class d can't be declared pure.
>
> If we change the example to be the following, I would still say it is
> illegal. In this version, abstract base class d is changing function f
> from
> a virtual to a pure virtual function. Since the definition of pure
> virtual
> is that there is no implementation, I don't see how this could be legal.
> It would be very confusing to say that the new definition of f in d
> overrides what is in c to now not have an implementation.
>
> module top;
> virtual class c;
> virtual function void f(int a); endfunction
> endclass
> virtual class d extends c;
> pure virtual function void f(int a);
> endclass
> endmodule
>
>
>
> Neil
>
>
>
> On 06/24/11 09:10, Gordon Vreugdenhil wrote:
>> This is just to follow-up the questions that I raised in the last EC
>> call.
>>
>> Is the following legal:
>>
>> module top;
>> virtual class c;
>> virtual function void f(int a); endfunction
>> endclass
>> class d extends c;
>> pure virtual function void f(int a);
>> endclass
>> endmodule
>>
>> There are a couple of questions about the legality:
>> 1) can "c" provide an implementation for a later
>> "pure virtual" prototype?
>> 2) if (1) is permitted, can "d" be non-virtual?
>> 3) if (1) is not permitted, can the "f" in some
>> further extension of "d" call "super.f"?
>>
>> If the "f" in "d" is supposed to "hide" the virtual
>> definition in "c" (which I find very troublesome),
>> is the prototype permitted to change? i.e. can you
>> then have:
>> pure virtual function void f(reg a);
>> as the prototype in "d" -- "hiding" generally means
>> the incompatibility is Ok.
>>
>> None of these situations are clearly addressed by
>> the current rules and definitely impact how we talk
>> about various interface class / class interactions.
>>
>> Gord.
>>
>

--
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.