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

A J Le Couteur Bisson <no***@nowhere. com> wrote:

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?
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.
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 :(

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 - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[100]

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" <no***@nowhere. com> wrote in message
news:bn******** **@newsfeed.th. ifl.net...

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

100 <10*@100.com> wrote:

The semantics is OK as long as you use type initlizers (static constructors)
to initlize the type.

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 - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[100]

Hi Jon,

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.

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

B\rgds
100

[A J Le Couteur Bisson]

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

A J Le Couteur Bisson <no***@nowhere. com> wrote:

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?

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.

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

100 <10*@100.com> wrote:

Hi Jon,

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.

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

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 - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[100]

Thank you Jon,

You are all about details :)

B\rgds
100

"Jon Skeet [C# MVP]" <sk***@pobox.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com...

100 <10*@100.com> wrote:

The semantics is OK as long as you use type initlizers (static constructors) to initlize the type.

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 - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[100]

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

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.

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]

In article <eS************ **@tk2msftngp13 .phx.gbl>, 10*@100.com says...

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.

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

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