RE: [sv-ec] 1800-2005 7.16 Chaining constructors - restriction needed

From: Mirek Forczek <mirekf_at_.....>
Date: Wed Apr 09 2008 - 02:48:06 PDT
The first solution that came to my mind was: local statement (here:
super.new(2) ) shall override a general one (here: ... extends B (1) ).
 
This way would be especially usefull if a class could contain more than one
constructor.
 
However, SV do not support overloading (in particular: class methods
overloading) currently, so there can be only 1:1 relation (inheritance spec.
: constructor spec.),
and from this point of view: 
    an error message about specifications conflict (" ... extends B (1) "
conflicts with "super.new(2)" - only one of them shall be present) is a good
solution too.
 
Anyway: is seems like the conflict nature is in C class text entirely, it
doesn't matter whether class B has an explicite constructor or not (this
could cause another kind of error of course: implicit constructor do not
takes a parameter).
So, I think: the "... becouse base constructor is already defined" comment
do not apply here.
 
Mirek 

  _____  

From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
Behalf Of danielm
Sent: 9 kwietnia 2008 11:29
To: sv-ec@server.eda.org
Subject: [sv-ec] 1800-2005 7.16 Chaining constructors - restriction needed



Chapter : 7.16 Chaining constructors :defines that there are 2 possible ways
to initialize base class constructor. IMHO there is lack of explicit
description what should happened if those both ways are used in the same
class.

There are two possible solution :it shoul be  forbidden. The other possible
solution is to define explicitly wich one should take precedence.

Cosnidre following example:

class B;
 function new (int i);
        $display(i);
endfunction
endclass

class C extends B (1);
        function new;
                super.new(2);//solution 1: this should trigger error becouse
base constructor is already defined
        endfunction
endclass


module top;
        C c=new;//solution 2: this should display 2 and LRM should
explicitly defines that super.new takes precedence on extends B(1)
endmodule


 

 

DANiel


-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> 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.
Received on Wed Apr 9 02:49:35 2008

This archive was generated by hypermail 2.1.8 : Wed Apr 09 2008 - 02:49:45 PDT