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

From: Neil Korpusik <neil.korpusik@oracle.com>
Date: Fri Jun 24 2011 - 15:55:40 PDT

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.
Received on Fri Jun 24 15:56:12 2011

This archive was generated by hypermail 2.1.8 : Fri Jun 24 2011 - 15:56:16 PDT