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

Gord,

In view of all the confusion caused by my comments, I withdraw my objection and switch my vote to yes.

BTW, I was trying not to shut the door on static constructors. Some languages support this special type of constructor to explicitly initialize static members even before creating an object of a particular class. C++ has a very clumsy mechanism for initializing static class members and SV relies either on the regular constructor or (like C++) explicit assignments using the class resolution for each static variable. Neither mechanism is OOP-like nor particularly good. It seems that a static constructor - which is indeed static and has no access to "this" although it mat have access to the static super-constructor - would be a good construct to have.

I realize that a static constructor would be a completely different type of beast - and certainly an enhancement that's outside the scope of the current LRM, but I was concerned that Dave's proposal would shut the door on such a mechanism. That is, live with the extant ambiguity and later associate an explicit semantic to a static constructor. I realize now that it's best to make it explicitly illegal and perhaps review the enhancement later.

Regarding the initialization ordering, I have reviewed your proposal and carefully read Steven's arguments. I have to admit that I find the arguments compelling and favor a change to the prescribed semantics. In my earlier comments I was simply trying to document the semantics of our implementation, but I recognize that threading initializers and constructors per class is a better semantic model and will support your proposal. This does leave us with a backward compatibility issue, but I hope it's not too severe as I expect these dependencies to be corner-cases that actual code does not rely on.

        Arturo

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Gordon Vreugdenhil
Sent: Friday, May 08, 2009 9:49 AM
To: jonathan.bromley@doulos.com
Cc: SV_EC List
Subject: 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.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.