Static Constructors run when the class is loaded.


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 14 of 14

Thread: Static Constructors run when the class is loaded.

  1. #1
    max caber Guest

    Static Constructors run when the class is loaded.


    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




  2. #2
    Kathleen Dollard Guest

    Re: Static Constructors run when the class is loaded.

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



  3. #3
    Bob Guest

    Re: Static Constructors run when the class is loaded.

    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

  4. #4
    max caber Guest

    Re: Static Constructors run when the class is loaded.


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



  5. #5
    Ronald Laeremans [MSFT] Guest

    Re: Static Constructors run when the class is loaded.

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

    >




  6. #6
    Rob Teixeira Guest

    Re: Static Constructors run when the class is loaded.


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



  7. #7
    Paul Mc Guest

    Re: Static Constructors run when the class is loaded.


    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

  8. #8
    Kathleen Dollard Guest

    Re: Static Constructors run when the class is loaded.

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



  9. #9
    max caber Guest

    Re: Static Constructors run when the class is loaded.


    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

  10. #10
    Rob Teixeira Guest

    Re: Static Constructors run when the class is loaded.


    "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


  11. #11
    Rob Teixeira Guest

    Re: Static Constructors run when the class is loaded.



    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):
    >



  12. #12
    Ronald Laeremans [MSFT] Guest

    Re: Static Constructors run when the class is loaded.

    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):
    > >

    >




  13. #13
    Rob Teixeira Guest

    Re: Static Constructors run when the class is loaded.


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



  14. #14
    Paul Vick [MSFT] Guest

    Re: Static Constructors run when the class is loaded.

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

    >




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center