Re: [sv-ec] RE: id 185, svdb 2342 static constructor

Jonathan,

I didn't really think that you expected "this"
to be illegal.  But it does make it clear that
"new" is a different kind of thing.  It really
is neither static nor automatic -- it follows
constructor rules.  So let's just not allow
static/automatic.  Explicit use of either is
very confusing; "new" is a constructor and
follows its own slightly different rules.

BTW, on the initialization ordering, please
see:
    http://www.eda.org/sv-ec/hm/6609.html

I disagree with your proposed ordering and
have explicitly discussed that variant in
that post.

Gord



jonathan.bromley@doulos.com wrote:
> Gord,
> 
>> So are you implying that the use of "this" 
>> in a constructor is illegal?
> 
> No, no!  Of course the constructor code MUST know
> about "this", a reference to the object that has
> rather recently been allocated and with whose
> contents the constructor code is busily messing.
> I was trying to play devil's-advocate and point out
> that new() most certainly is not an ordinary method.
> For example, I'm sure you would object strongly if
> I tried to do the following:
> 
>    C c = new();  // create and initialize c
>    c.whatever(); // do something to c's contents
>    c.new();      // reset c to its initial state (!!!)
> 
> So the rules for new() must, whatever, be special.
> Consequently, whether new() is static or not is
> really splitting hairs, isn't it?  And I apologize
> that I was guilty of continuing to split those 
> hairs, unnecessarily.
> 
> We have precisely two forms of call to new(), don't we?
>     handle = new(...);
> and
>     super.new(...); (whether implicit or explicit)
> 
> The first of these:
>   - allocates and default-initialises the new object
>   - runs explicit initializations on member variables
>   - runs the user constructor code
>   - returns the value of "this" 
> The second form... 
>   - only runs the user code????
> 
> Given this limited set of possibilities it shouldn't
> be too hard to write a bunch of rules that say exactly
> what each does, including rules about the constructor
> arguments and so on.  As I've said before, speaking as
> a user I'd be happy to accept ANYTHING realistic here;
> I don't much care about the relative merits of existing
> languages, but I do care a lot about clear definition,
> portability, and freedom from obscure corner cases.
> 
> The initialization sequence that I personally think
> would be easiest to understand is....
> 
> 1. allocate the whole derived-class object
> 2. default-initialize all its data members
> 3. run explicit data member initializers,
>    deepest base class first
> 4. call user constructor for the derived 
>    class; since that calls super.new as its
>    first statement, that means user constructors
>    also get executed in deepest-base-first order,
>    but it means that constructor arguments get
>    evaluated in most-derived-first order.
> 
> But if there are good reasons for doing something
> different, I would not argue with them.

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