Re: [sv-bc] Question on pure virtual function

But elaboraters already have a type-checking detector at the right code
location,
since they should be catching things like unpacked types being sent via
type parameters
into bad contexts such as being the element type of a packed array. 
There are a
few of these rules that can be challenged by passing type parameters.

Gordon Vreugdenhil wrote:
>
> Well, there generally isn't a very good reason to have the
> base class defined after the derived class in the same section
> of code so I would consider that to be at least bad style.
>
> More interesting are type parameter cases (which are conceptually
> similar):
>
>     class B;
>     endclass;
>
>     module child #(type base = B);
>       class derived extends base;
>       endclass
>     endmodule
>
>     module top;
>       virtual class base;
>          pure virtual function int f();
>       endclass
>       child #(base) c();
>     endmodule
>
> This design should cause an error since the actual type of "base"
> provided to "child" is abstract and "derived" does not override "f".
> The enforcement of the class relationship rules are the same; the
> time at which a particular implementation might "notice" the error
> could vary but will definitely be prior to simulation time and
> does not depend on the existence of a "new" call (the error is
> purely a function of the type relationships).
>
> Gord.
>
>
> Surya Pratik Saha wrote:
>> Hi Gordon,
>> Thanks for the reply. I have another question, if the virtual base
>> class is a typedef which is declared later then how it will be
>> handled. For e.g.
>>
>> typedef class base;
>> class derived extends base;
>> endclass
>>
>> virtual class base;
>>    pure virtual function int f();
>> endclass
>>
>> Regards
>> Surya
>>


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