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

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Wed Jun 25 2008 - 10:56:45 PDT
Jonathan Bromley wrote:
> [Gord]
> 
>> During construction, you cannot safely call an
>> overridden method since the derived class state would not have
>> been initialized yet.  As with C++ (ISO C++ 1998, Sec 12.7),
>> SV should clarify that during construction you effectively
>> change your vtbl as construction progresses so that you only
>> get "the most derived" override vis-a-vis the type of "new"
>> that you are currently executing.
> 
> This is rather self-evidently sensible, but current tools
> are not unanimous about it; currently I count one in Gord's
> favour, two in Chris's.  At present I recommend to people 
> that they should completely avoid calling virtual methods 
> from a constructor.

There are many aspects of SV that are still maturing in
terms of catching up to reasonable and well formed
definitions.  This is yet another one.  This has come
up in past discussions I believe (at least in meetings)
and I haven't heard anyone seriously defend the other
behavior as being more desirable and better for the
language, particularly as things continue to move forward.

There are other issues in this space that are also
still somewhat indeterminate.  For example, an explicit
"super.new" must be "first".  What constitutes "first"?
What if there are local variables in "new" that are
initialized via a function call (virtual??)?

All of this really needs to be cleaned up and brought
into closer alignment with approaches in other languages
where this has been considered much more carefully.

> While we're thinking about constructors, can I raise something
> I've been meaning to ask for ages?  The constructor is, in
> many respects, a static method.  If new() could be treated
> truly as a static method, then we could get this rather
> convenient idiom:
> 
>   class C;...
>   class D extends C; ...
>   ...
>   C c;
>   c = D::new();
> 
> Is there any fundamental problem with this that I've missed?

I don't have too much concern over this.  This does further
intertwine the "allocation" and "construction" aspects since
the "allocation" would be implicitly controllable by the
type prefix, but since there are likely deeper issues with
allocation separation (as possible in C++), I don't think
that I would be opposed.

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.
Received on Wed Jun 25 10:57:16 2008

This archive was generated by hypermail 2.1.8 : Wed Jun 25 2008 - 10:57:24 PDT