Re: [sv-ec] sub-class constructor

Alsop, Thomas R wrote:
> Hi Gord,
>
 > I didn't quite understand the two examples you gave below. Are you
 > basically saying the C++ infers arguments passed in super.new() child
 > calls and that SV is not clear on this?

No, my example was dealing only with the semantics of virtual method
calls during construction.  In particular whether it is well-defined
which virtual method should be called from which of the constructors
during the constructor call chain.

 > I can appreciate the Doulos documentation given the shortcomings in
 > the SV LRM.  Wasn't sure if this was given as SV gospel or
 > methodology.  Seems like it should be a methodology statement.  I
 > believe the VMM has this as a 'Rule' or 'Guideline', i.e. always call
 > super.new(), with arguments if needed, when child constructors are
 > defined.

Sure, that is a methodology statement.  Clearly you MUST explicitly
call super.new if there are non-defaulting arguments, but in other
situations it is purely a methodology issue.

 > The virtual aspect comes into play depending on the usage model,
 > right?  If you want your base classes constructors to be 'overriden'
 > (i.e. polymorphism) but still include the super.new() functionality,
 > then your child new() definition would call super.new().  If you want
 > to completely change what all the extended classes do up to the base,
 > then the child new() definition would not call super.new(), right?

No.  The question of which virtual would be called is orthogonal
to the question of how super.new is invoked.


 > In the case of non-virtual child new() calls, again, calling
 > super.new() really depends on whether the end user want to completely
 > override the super.new() or not.  Although it doesn't sound like good
 > practice, this may be something they want or need in the extended
 > class.

Hmm.  Perhaps the Doulos discussion of "overriding" new has confused
you a bit.  "new" is NEVER virtual and "super.new" is ALWAYS called
(either explicitly or implicitly).

 > Seems to me that we shouldn't define the SV LRM to implicitly call
 > super.new() in child extensions, rather we should state that this will
 > not be the case and let the methodologies that are out there recommend
 > this practice.

I would very strongly oppose this direction.  Only doing base-class
constructor calls when there is an explicit call would lead to all sorts
of bizarre errors and interactions in terms of class construction
state.  Requiring EVERY derived class to explicitly define "new" and
to explicitly make a base class constructor call would alleviate that
problem but would likely be strongly opposed from many users since that
means that even trivial classes would require a "new" method to be defined.

Gord.

-- 
--------------------------------------------------------------------
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.