Static constructors

  • Thread starter Thread starter A J Le Couteur Bisson
  • Start date Start date
A

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.GetTypeFromCLSID be
documented
clearly as unimplemented? The help gives the following:

Parameters
clsid
The CLSID of the type to get.
Return Value
System.__ComObject 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
 
A J Le Couteur Bisson said:
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?
Click to expand...

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 :(
Click to expand...

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.
 
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 *beforefieldinit* 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 *beforefieldinit* 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
 
100 said:
The semantics is OK as long as you use type initlizers (static constructors)
to initlize the type.
Click to expand...

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.
 
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.
Click to expand...

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

B\rgds
100
 
Jon Skeet said:
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.
Click to expand...

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.GetTypeFromCLSID 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
 
100 said:
Hi Jon,

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

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.
 
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.
Click to expand...
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.
 
Just a little correction. C++ has never had static constructors or type
initilizers.
Click to expand...

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