Re: [sv-ec] Prohibit overriding data members of a class?

Jonathan,

I think you are confusing "hiding" with "overriding".

Class inheritance creates a layering of class aspects
in which later definitions can "hide" earlier ones.
So the "D" object has TWO versions of "N" and get_N().  For
example, you can do:

   class D extends C;
     int N = 4;
     function int get_N();
          return N + super.get_N() + super.N;
     endfunction
   endclass

and you should see "10".

I know of at least one implementation that gets this answer.  :-)


You only "override" a virtual function in which case the
meaning of a name changes even when referring to the method
by way of a base class pointer.

In your example, if you add:
     c = d;
     $display("%d", c.get_N());
you'll get a "3".  "get_N" isn't virtual so when you access
get_N you get the version of the method defined by the handle
type, not the one defined by the actual object.  If get_N
was virtual, you would get the one from "D" even after the
assignment of "c = d;".


In short, whatever implementation you were using has a bug and
I think the bug is causing you some confusion.

Gord.

Jonathan Bromley wrote:
> hi EC,
> 
> I recently had a query from a student who had tried to 
> override a *data* member of a class...
> 
>   class C;
>     int N = 3;
>     function int get_N(); return N; endfunction
>   endclass
>   class D extends C;
>     int N = 4;
>     function int get_N(); return N; endfunction
>   endclass
>   ...
>   ...
>   D d = new;
>   C c = new;
>   $display(c.get_N()); // "3" as expected
>   $display(d.get_N()); // "3" seen ???!!!
> 
> (By the way, I don't even know which simulator this person
> was using.)
> 
> It seems to me that this should be illegal, and you should
> be able to override only methods, not data members.  Although
> the LRM hints as much, I can't find an explicit prohibition
> of overriding a data member, nor a description of what to do
> should it occur.
> 
> Any other opinions?  Is this just a compiler failing to
> report an error, or have I missed something?  Do we need
> some minor LRM clarification for this?

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


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