Static constructors

[A J Le Couteur Bisson]

Could someone please confirm that static class constructors are only called
at the first
use of a non-static constructor on the class, or am I doing something wrong?
If this is
indeed the case then I would consider this a serious error in the language
implementation,
not to mention a pain in the backside :(

Also, is it to much to ask that the method Type.GetTypeFro mCLSID be
documented
clearly as unimplemented? The help gives the following:

Parameters
clsid
The CLSID of the type to get.
Return Value
System.__ComObj ect regardless of whether the
CLSID is valid.

and then goes on to provide an example of this pointless function in use. I
wouldn't mind
but I have used this function and, of course, it doesn't work.

Andy

[Jon Skeet [C# MVP]]

Re: Static constructors

A J Le Couteur Bisson <noone@nowhere. com> wrote:[color=blue]
> Could someone please confirm that static class constructors are only called
> at the first use of a non-static constructor on the class, or am I doing
> something wrong?[/color]

No, they're called either when the first instance is created or when
any static field of the type is referenced.

They can also be called using reflection.
[color=blue]
> If this is indeed the case then I would consider this a serious error in
> the language implementation, not to mention a pain in the backside :([/color]

I think the semantics are fine, and far from a serious error at all.
Are you expecting all the static constructors to be executed when an
assembly loads, in a similar way to some C++ code? If so, then it
sounds like your problem is trying to apply an idiom from one
environment to another.

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[100]

Re: Static constructors

Hi A J,
Speeking of CLR there is two policies for calling static constructors.
1. By default. The static constructor of a type is called at the first
access to a member of the class(either static or instance).
2. When a type is marked with *beforefieldini t* attribute. CLR is free to
call the type initilizer at the first access to any member of the type or
the type initilizer call can be postponed until the first access to a static
field (not method) of the type. So CLR has more freedom.
Which means that there is no guarantee that when you start creating and
using instances of the class the static constructor is already called. It
might not get called at all.

C# sets *beforefieldini t* attribute for all classes that lack explicit
static constructor declaration and doesn't set it if static constructor is
declared. It does that regardless of wheter static fields have initlializer
expressions on their declarations or not.

The semantics is OK as long as you use type initlizers (static constructors)
to initlize the type. It is not good idea (I believe it is bad design) if
you try to do more work then that in a static constructor.

HTH
B\rgds
100


"A J Le Couteur Bisson" <noone@nowhere. com> wrote in message
news:bno4ud$oud $1@newsfeed.th. ifl.net...[color=blue]
> Could someone please confirm that static class constructors are only[/color]
called[color=blue]
> at the first
> use of a non-static constructor on the class, or am I doing something[/color]
wrong?[color=blue]
> If this is
> indeed the case then I would consider this a serious error in the language
> implementation,
> not to mention a pain in the backside :(
>
> Also, is it to much to ask that the method Type.GetTypeFro mCLSID be
> documented
> clearly as unimplemented? The help gives the following:
>
> Parameters
> clsid
> The CLSID of the type to get.
> Return Value
> System.__ComObj ect regardless of whether the
> CLSID is valid.
>
> and then goes on to provide an example of this pointless function in use.[/color]
I[color=blue]
> wouldn't mind
> but I have used this function and, of course, it doesn't work.
>
> Andy
>
>[/color]

[Jon Skeet [C# MVP]]

Re: Static constructors

100 <100@100.com> wrote:[color=blue]
> The semantics is OK as long as you use type initlizers (static constructors)
> to initlize the type.[/color]

Note that there's a difference between a static constructor and a type
initializer. A static constructor is a C# concept; a type initializer
is a .NET concept.

A class without a static constructor can still have a type initializer
(due to static fields being initialized, etc). I suspect you (100)
understand this, but it's worth keeping the two terms distinct.

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[100]

Re: Static constructors

Hi Jon,[color=blue]
> I think the semantics are fine, and far from a serious error at all.
> Are you expecting all the static constructors to be executed when an
> assembly loads, in a similar way to some C++ code? If so, then it
> sounds like your problem is trying to apply an idiom from one
> environment to another.[/color]

Just a little correction. C++ has never had static constructors or type
initilizers.

B\rgds
100

[A J Le Couteur Bisson]

Re: Static constructors


"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1a09aa 00720bee8d98998 2@msnews.micros oft.com...[color=blue]
> A J Le Couteur Bisson <noone@nowhere. com> wrote:[color=green]
> > Could someone please confirm that static class constructors are only[/color][/color]
called[color=blue][color=green]
> > at the first use of a non-static constructor on the class, or am I doing
> > something wrong?[/color]
>
> No, they're called either when the first instance is created or when
> any static field of the type is referenced.
>
> They can also be called using reflection.[/color]

This is a helpful observation. I am trying to register business object
types
so that I can reference them by their Guid (In the way that I assume
Type.GetTypeFro mCLSID will eventually work.) I would prefer that
these business object type automatically register by adding themselves
to a Guid->Type hashtable. Scanning the types defined in the assembly
via reflection will do this so all is well

Thanks,
Andy

[Jon Skeet [C# MVP]]

Re: Static constructors

100 <100@100.com> wrote:[color=blue]
> Hi Jon,[color=green]
> > I think the semantics are fine, and far from a serious error at all.
> > Are you expecting all the static constructors to be executed when an
> > assembly loads, in a similar way to some C++ code? If so, then it
> > sounds like your problem is trying to apply an idiom from one
> > environment to another.[/color]
>
> Just a little correction. C++ has never had static constructors or type
> initilizers.[/color]

Absolutely - but "some C++ code" is executed on startup. I wasn't
meaning to imply that C++ had type initializers or static constructors
like .NET/C# has.

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[100]

Re: Static constructors

Thank you Jon,

You are all about details :)

B\rgds
100

"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1a09e9 48b138f18c98998 9@msnews.micros oft.com...[color=blue]
> 100 <100@100.com> wrote:[color=green]
> > The semantics is OK as long as you use type initlizers (static[/color][/color]
constructors)[color=blue][color=green]
> > to initlize the type.[/color]
>
> Note that there's a difference between a static constructor and a type
> initializer. A static constructor is a C# concept; a type initializer
> is a .NET concept.
>
> A class without a static constructor can still have a type initializer
> (due to static fields being initialized, etc). I suspect you (100)
> understand this, but it's worth keeping the two terms distinct.
>
> --
> Jon Skeet - <skeet@pobox.co m>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too[/color]

[100]

Re: Static constructors

[color=blue][color=green]
> > Just a little correction. C++ has never had static constructors or type
> > initilizers.[/color]
>
> Absolutely - but "some C++ code" is executed on startup. I wasn't
> meaning to imply that C++ had type initializers or static constructors
> like .NET/C# has.[/color]
Yes, there is of course startup code (which is big times less than what is
executed when a .NET application starts :-) )
About initializing static fileds - if static fields of class use
initializers that in turn use only constant expressions there won't be any
initlizing code for that particular class.
For example the declaration

class Foo
{
static char* Name;
satitc int IntVal;
static const Const = 10;
};

char* Foo::Name = "Foo class";
int Foo::IntVal = 100 + Const;

won't have any init code behind.

But yes, if you have function calls, non-constant variables or new operator,
c++ compiler will generate initializing code.


B\rgds
100.

[Guinness Mann]

Re: Static constructors

In article <eSt#KXjnDHA.30 24@tk2msftngp13 .phx.gbl>, 100@100.com says...[color=blue][color=green]
> > Are you expecting all the static constructors to be executed when an
> > assembly loads, in a similar way to some C++ code? If so, then it
> > sounds like your problem is trying to apply an idiom from one
> > environment to another.[/color]
>
> Just a little correction. C++ has never had static constructors or type
> initilizers.[/color]

So what's the worst problem, then? Applying an idiom from one
environment to another, or making up an environment to accuse someone of
applying to a different environment? ;-)

-- Rick