RE: [sv-ec] Virtual function call from base class constructor

Jonathan,

 

With regards to your first question, the LRM says:

 

When using the super within new, super.new shall be the first statement
executed in the constructor.

 

So your code snippet is legal: the ternary operation is not a statement;
it is an argument expression.

 

I agree that the definition of what is the "first statement" can be
further improved, particularly, when it applies to harmless and
seemingly well-behaved code, such as Gord's example of initializing
variables local to the constructor - though perhaps not via virtual
method calls. As written now, however, such statements preceding the
call to super.new would violate the current LRM.

 

One detail that seems to be eluding this discussion is that
SystemVerilog's object-oriented mechanism is largely based on Java, not
on C++ or C#. In fact, the rule requiring super.new to be the first
statement is a direct derivation of Java's rule.

 

Likewise, Java's virtual method handling differs from C++. In Java,
calling a virtual method invokes the derived class's version. Since, the
derived class may not have been initialized at the point of the call,
calling (virtual or non-final) methods in a constructor will usually
trigger strange behavior or null-pointer exceptions. One way to avoid
these problems is to only call private methods in constrictors. Books on
Java are full of dire warnings against calling derived methods in
constructors. For example: "Thinking in Java", makes this point:

 

Conceptually, the constructor's job is to bring the object into
existence (which is hardly an ordinary feat). Inside any 

constructor, the entire object might be only partially formed-you can
know only that the base-class objects have been 

initialized, but you cannot know which classes are inherited from you. A
dynamically bound method call, however, 

reaches "outward" into the inheritance hierarchy. It calls a method in a
derived class. If you do this inside a constructor, 

you call a method that might manipulate members that haven't been
initialized yet-a sure recipe for disaster."

 

It is unfortunate that the LRM doesn't explicitly specify the behavior
of virtual methods in constructors. And that omission has lead to the
current discussion. But rather than attempt to copy C++, I would suggest
that we consider SV's pedigree in favor of the simpler Java model.

 

Regardless of where one falls in this discussion, one thing that we can
all agree on is that calling virtual methods from within constructors is
not a good practice and should be discouraged. I would propose we add a
note stating that this should be avoided - we might go further and
state that doing so may result in undefined behavior, which would simply
acknowledge the reality that implementations seem to have diverged. The
more complex C++ mechanism attempts to protect users, and while it its
behavior is more compartmentalized, it doesn't completely eliminate the
problem - the dependencies between (uninitialized) variables and the
virtual method's use of such variables is still there. 

 

            Arturo

 

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Jonathan Bromley
Sent: Wednesday, June 25, 2008 11:05 AM
To: Gordon Vreugdenhil
Cc: Chris Spear; Daniel Mlynek; sv-ec@eda.org
Subject: RE: [sv-ec] Virtual function call from base class constructor

 

 

> "super.new" must be "first".  What constitutes "first"?

 

yes; for example, is this OK?  I can easily see why it might

not be, but I can also see why I might wish to do it:

 

  class C; function new(int N); ...

  class D extends C;

    function new(int N);

      super.new( N>0 ? N : 0 );

      ...

 

 

> >   c = D::new();

> > Is there any fundamental problem with this that I've missed?

> 

> I don't have too much concern over this.

 

But I had not thought about Dave Rich's point:

> [DR] Except that the "this" handle is not available

> in static methods, and needs to be available in a constructor.

 

Thanks

-- 

Jonathan Bromley, Consultant

 

DOULOS - Developing Design Know-how

VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

 

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24
1AW, UK

Tel: +44 (0)1425 471223                   Email:
jonathan.bromley@doulos.com

Fax: +44 (0)1425 471573                           Web:
http://www.doulos.com

 

This message may contain personal views which 

are not the views of Doulos Ltd., unless specifically stated.

 

-- 

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.