Static Constructors run when the class is loaded.

[max caber]

Ronald responded to my post regarding when static constructors run as follows,
"No, that is simply not the guarantee the CLR makes. The guarantee is exactly
as I stated."

Sorry Ronald,
Static constructors run when the class is loaded. This occurs BEFORE a new
instance of a class is created, or BEFORE a static member is referenced.


Run the following and you will get the same output that I did. If it words
differently in VB.NET then in C#, then we have a big problem:

using System;

namespace Constructors
{
class A
{
static int x = 5;
static A()
{
Console.WriteLine("static constructor ran");
x=10;
}
public static int X
{
get{return x;}
}
}
class ClientMain
{
static void Main(string[] args)
{
Console.WriteLine("About to create a new A");
A a = new A();
Console.WriteLine("Created a new A");
Console.WriteLine("About to reference a static member");
Console.WriteLine("A.a:= " + A.X);
Console.WriteLine("Referenced a static member");

}
}
}

Outputs the following:

About to create a new A
static constructor ran
Created a new A
About to reference a static member
A.a:= 10
Referenced a static member
Press any key to continue

[Kathleen Dollard]

Max,

Why would you _ever_ care when a static constructor is run? Are you saying
that the spec is different in VB.NET and C#? I am trying to figure out what
part of Ronald's statement you disagree with. He told you when it ran, it
runs when it says it will run, what is the issue?

--
Kathleen
(MS-MVP)
Reply in the newsgroup so everyone can benefit
--

[Bob]

In article <3bba0e75@news.devx.com>, kathleen@nomailplease.org says...
> Max,
>
> Why would you _ever_ care when a static constructor is run? Are you saying
> that the spec is different in VB.NET and C#? I am trying to figure out what
> part of Ronald's statement you disagree with. He told you when it ran, it
> runs when it says it will run, what is the issue?
>
> --
> Kathleen
> (MS-MVP)
> Reply in the newsgroup so everyone can benefit
> --

It sounds like Ronald is saying that the spec says it will run at some
unspecified time BEFORE some specific point in time, and Max is saying that
in its current implementation it runs AT some specific point in time, where
the two points in time are currently different.

Ronald is rightfully warning us NOT to write code that depends upon the
constructor running at any particular point in time as the spec doesn't
guarantee that.

Bob

[max caber]

Kathleen,
You ask,
Q."Why would you _ever_ care when a static constructor is run?"
A.Are you joking, or just trying to piss me off. Because this is a good
place to open non managed resources, such as database connections and files
that are to be shared between different instances of the particular class.
When files and DB connections are opened and closed is considered important
to most developers.

Also, I thought by providing a simple sample application that demonstrates
how this works would help some readers of this ng. You can run my app for
yourself, change the code, so that the static member is referenced before
the class is instanciated to see the results are still the same.

This Kathleen, I think most people would agree is more informative then your
remark, "He told you when it ran, it runs when it says it will run."

Kathleen, why don't you or Ronald show me some code that makes a static constructor
run after the class is loaded. Yes, this is a chanlenge to put up or shut
up!
Max



"Kathleen Dollard" <kathleen@nomailplease.org> wrote:
>Max,
>
>Why would you _ever_ care when a static constructor is run? Are you saying
>that the spec is different in VB.NET and C#? I am trying to figure out what
>part of Ronald's statement you disagree with. He told you when it ran, it
>runs when it says it will run, what is the issue?
>
>--
>Kathleen
>(MS-MVP)
>Reply in the newsgroup so everyone can benefit
>--
>
>

[Ronald Laeremans [MSFT]]

Hi Max,

You really are missing my point (apart from the fact that Jeff correctly
pointed out it depends on whether the BeforeFieldInit bit is set, which I
thought all MS languages were doing, I haven't checked out what the VB
compiler emits):

It does not matter one bit what the current implementation does. What does
matter is what semantics we are guaranteeing. If you depend on semantics
that are not in the spec, but that happen to just be there because we did
not implement some optimization, you are setting yourself up for your code
to break in very subtle ways when we ship newer versions of the CLR. I
really don't understand why you would want to do that.

If your static constructor opens a database connection that is to be shared
across all instances of this class, where are you going to store that
connection handle anyway if not in a static field of the class?

Ronald Laeremans
Visual C++ compiler team

"max caber" <maxcaber@yahoo.com> wrote in message
news:3bba1875$1@news.devx.com...
>
> Kathleen,
> You ask,
> Q."Why would you _ever_ care when a static constructor is run?"
> A.Are you joking, or just trying to piss me off. Because this is a good
> place to open non managed resources, such as database connections and
files
> that are to be shared between different instances of the particular class.
> When files and DB connections are opened and closed is considered
important
> to most developers.
>
> Also, I thought by providing a simple sample application that demonstrates
> how this works would help some readers of this ng. You can run my app for
> yourself, change the code, so that the static member is referenced before
> the class is instanciated to see the results are still the same.
>
> This Kathleen, I think most people would agree is more informative then
your
> remark, "He told you when it ran, it runs when it says it will run."
>
> Kathleen, why don't you or Ronald show me some code that makes a static
constructor
> run after the class is loaded. Yes, this is a chanlenge to put up or shut
> up!
> Max
>
>
>
> "Kathleen Dollard" <kathleen@nomailplease.org> wrote:
> >Max,
> >
> >Why would you _ever_ care when a static constructor is run? Are you
saying
> >that the spec is different in VB.NET and C#? I am trying to figure out
what
> >part of Ronald's statement you disagree with. He told you when it ran, it
> >runs when it says it will run, what is the issue?
> >
> >--
> >Kathleen
> >(MS-MVP)
> >Reply in the newsgroup so everyone can benefit
> >--
> >
> >
>

[Rob Teixeira]

Max,

I agree that it's good to show sample code. Your example, as stated below,
is indeed useful information.
However, the point Ronald is bringing up is simply this:
The CLS specifies a contract that must be adhered to in regards to when this
action takes place. What you have demonstrated is when the action takes place
under this implementation of the CLR. However, future implementations of
the CLR, or a CLR built for another platform, does not need to adhere to
this (current) behavior, since it isn't part of the contract, so the programmer
must be aware of this when he is designing his code. IWO, while the behavior
is a certain way right now, that might not be true for all cases (in the
future).

I don't think (or hope) that anyone is intentionally trying to get into a
pissing match with you.

-Rob

"max caber" <maxcaber@yahoo.com> wrote:
>
>Kathleen,
>You ask,
>Q."Why would you _ever_ care when a static constructor is run?"
>A.Are you joking, or just trying to piss me off. Because this is a good
>place to open non managed resources, such as database connections and files
>that are to be shared between different instances of the particular class.
> When files and DB connections are opened and closed is considered important
>to most developers.
>
>Also, I thought by providing a simple sample application that demonstrates
>how this works would help some readers of this ng. You can run my app for
>yourself, change the code, so that the static member is referenced before
>the class is instanciated to see the results are still the same.
>
>This Kathleen, I think most people would agree is more informative then
your
>remark, "He told you when it ran, it runs when it says it will run."
>
>Kathleen, why don't you or Ronald show me some code that makes a static
constructor
>run after the class is loaded. Yes, this is a chanlenge to put up or shut
>up!
>Max
>
>

[Paul Mc]

Max.

>A.Are you joking, or just trying to piss me off.
snip
>Yes, this is a chanlenge to put up or shut up!

Get a grip.

The point everyone is trying to get through to you is that the way it currently
works is *not guaranteed*, and therefore not safe to rely on. It could well
change between now and version two - or now and version 1 for that matter.

Sample code that demonstrates certain behaviour is always valuable - and
generally appreciated by those of us who are actually looking at VS.Net.
Certainly no-one is saying that your code was invalid, or that the results
you claim were false. It was simply stated that this behaviour *can not*
be relied upon to remain unchanged.

BTW, in my experience, Kathleen has been one of the most reasonable voices
in this ng, and far from trying to piss people off, is nearly universally
polite and respectful of others.

As for "put up or shut up", well I have no comment - apart from ***?

Paul

[Kathleen Dollard]

Max,

> Q."Why would you _ever_ care when a static constructor is run?"
> A.Are you joking, or just trying to piss me off. Because this is a good
> place to open non managed resources, such as database connections and
files
> that are to be shared between different instances of the particular class.
> When files and DB connections are opened and closed is considered
important
> to most developers.

Well, I am not trying to piss you off. Just trying to determine how you
would be opening the connection or file, using it and not accessing a
reference to it?

When someone first explained the lack of knowing when this particular event
fired (which I think is a very cool event, btw) I argued quite foolishly
that it was critical that I know exactly when the event would fire. Happily,
that was in the real world, so no record remains of my own feeble attempts
to defend my desire for total power over my code. Perhaps you will see a
real world (not horrible design just to prove a point, btw) and redeem my
position in that earlier conversation. I was unable to.

When the event happens to fire now is not at all important. It is when the
contract with the language says it will fire that matters. We have a clear
specification, and it seems wise to use it. If you see a flaw in the spec,
then get the spec changed rather than talking about what the current
behavior happens to be.

Of course if you need it to fire when the first instance is created, or
before, you can tap on a shared member (set it to itself) in the instance
constructor. But do you seriously see a flaw in the spec here?

--
Kathleen
(MS-MVP)
Reply in the newsgroup so everyone can benefit
--

[max caber]

Ok what ever the spec says is what the spec says.
But I still promise that after .NET is released, there will be no code that
shows a static constructor running after any thing else, for a class. Why,
because static constructors initialize static fields, and all instances of
a class, and all static methods, may access those static fields. Therefore,
the static constuctor must be the first thing to run.

Now if you want something that you can not be sure of, lets talk about instance
deconstructors/Finalizers, because when they run depends on their "generation"
, if the compiler is optimized to "read ahead", or if they have been "resurrected"
from a previous instance. Then create a "weak reference" to a class with
a Finalizer and let the confusion really begin.
Best bet is to provide a "Dispose()" method.
Max

[Rob Teixeira]

"max caber" <maxcaber@yahoo.com> wrote:
>
>Now if you want something that you can not be sure of, lets talk about instance
>deconstructors/Finalizers, because when they run depends on their "generation"
>, if the compiler is optimized to "read ahead", or if they have been "resurrected"
>from a previous instance.

Well, that's partly why they call it non-deterministic finalization

>Then create a "weak reference" to a class with
>a Finalizer and let the confusion really begin.

A weak reference won't necessarily mess with the finalization call in and
of itself. In its simplest form, a weak reference allows GC to continue as
normal, and if the reference is accessed, a null is returned.
The abnormal behaviour is a product of a "long weak reference", which allows
resurrection.

>Best bet is to provide a "Dispose()" method.

Absolutely.

-Rob

[Rob Teixeira]

Ron,

I wonder if you can clarify this further. I thought this bit was set on a
type by type basis (rather than being set by the language for all types -
is that what you mean?).
For example, checking the bit of the type attributes (in a small test I did)
for a reference type generated by VB results in 0, while this attribute flag
was turned on for a boxed value type.

-Rob

"Ronald Laeremans [MSFT]" <ronlaere@microsoft.com> wrote:
>Hi Max,
>
>(apart from the fact that Jeff correctly
>pointed out it depends on whether the BeforeFieldInit bit is set, which
I
>thought all MS languages were doing, I haven't checked out what the VB
>compiler emits):
>

[Ronald Laeremans [MSFT]]

Yes, I thought all languages were setting this bit on all the types they
emit. I have now verified that I am wrong. No Microsoft .NET languages
actually set this bit, which is by design in C#, which is a bug we will fix
in the next version for MC++ and which I don't know was intended or not for
VB.

-Ronald-

"Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
news:3bbb2f09$1@news.devx.com...
>
>
> Ron,
>
> I wonder if you can clarify this further. I thought this bit was set on a
> type by type basis (rather than being set by the language for all types -
> is that what you mean?).
> For example, checking the bit of the type attributes (in a small test I
did)
> for a reference type generated by VB results in 0, while this attribute
flag
> was turned on for a boxed value type.
>
> -Rob
>
> "Ronald Laeremans [MSFT]" <ronlaere@microsoft.com> wrote:
> >Hi Max,
> >
> >(apart from the fact that Jeff correctly
> >pointed out it depends on whether the BeforeFieldInit bit is set, which
> I
> >thought all MS languages were doing, I haven't checked out what the VB
> >compiler emits):
> >
>

[Rob Teixeira]

Thanks Ron.

Can anyone verify the flag being turned on for reference types and off for
value types emitted by the VB compiler? (and why that may be the case?)

-Rob

"Ronald Laeremans [MSFT]" <ronlaere@microsoft.com> wrote:
>Yes, I thought all languages were setting this bit on all the types they
>emit. I have now verified that I am wrong. No Microsoft .NET languages
>actually set this bit, which is by design in C#, which is a bug we will
fix
>in the next version for MC++ and which I don't know was intended or not
for
>VB.
>
>-Ronald-
>

[Paul Vick [MSFT]]

Let me attempt to clarify a bit. The semantics that both C# and VB implement
is, the BeforeFieldInit flag is set if and only if you have static/shared
fields but have not explicitly defined a static/shared constructor for the
class. I forget when this was implemented (i.e. before or after Beta2), but
the behavior is observable in both the C# and VB compilers that I have on my
machine right now.

Paul Vick [MSFT]

--
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. © 2001 Microsoft Corporation. All rights
reserved.

"Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
news:3bbb610b$1@news.devx.com...
>
> Thanks Ron.
>
> Can anyone verify the flag being turned on for reference types and off for
> value types emitted by the VB compiler? (and why that may be the case?)
>
> -Rob
>
> "Ronald Laeremans [MSFT]" <ronlaere@microsoft.com> wrote:
> >Yes, I thought all languages were setting this bit on all the types they
> >emit. I have now verified that I am wrong. No Microsoft .NET languages
> >actually set this bit, which is by design in C#, which is a bug we will
> fix
> >in the next version for MC++ and which I don't know was intended or not
> for
> >VB.
> >
> >-Ronald-
> >
>