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

c::f is virtual so call to f is a call to f function in current object.
In yours case e::f has to be called there is no other option.
I do not understand why " d::f() must have a valid override of c::f() "
d::f will never be called as we cannot create object of c type.
If user will try to call super.f in e::f or d::f in e::f then runtime
error can be printed that pure function was called.

DANiel

On 6/27/2011 6:32 PM, Tipp, Brandon P wrote:
> 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.