Static constructors in C# will be the death of me
-
Why oh why can't we just have static constructors either a) execute at App start, or (if you are picky about not having your app take 5 mins to start up), b) execute before any static method of the class is executed Instead of having them execute only when an actual object of the class is instantiated. :mad:
cheers, Chris Maunder
CodeProject.com : C++ MVP
For the same reason that C# doesn't have const, default values, and other nice stuff. Because no thought went into it, beyond what can be done in the designer. And for the same reason that switch statements are so restricted in C#, the designers assume you don't know enough about programming to use a static constructor anyhow. I love some things about C#, but too often, it's just dumb.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
Why oh why can't we just have static constructors either a) execute at App start, or (if you are picky about not having your app take 5 mins to start up), b) execute before any static method of the class is executed Instead of having them execute only when an actual object of the class is instantiated. :mad:
cheers, Chris Maunder
CodeProject.com : C++ MVP
Chris Maunder wrote:
Why oh why can't we just have static constructors either a) execute at App start, or (if you are picky about not having your app take 5 mins to start up), b) execute before any static method of the class is executed Instead of having them execute only when an actual object of the class is instantiated.
Because that would mean that the programmers at Microsoft were wrong in the first place. Maybe it's not applicable but have you thought of using a singleton pattern (there's a generic one on this very site which is very handy). If you look for it it's the one which uses reflection and involves one line of code.
If you're stuck in a rut: 1) Consult the documentation* 2) Google it 3) Ask a sensible question 4) Try an ancient ritualistic knowledge summoning (:badger::badger::badger:) dance :jig: 5) Phone :bob: * - If the documentation is MSDN > 6.0 then forget it!
-
Why oh why can't we just have static constructors either a) execute at App start, or (if you are picky about not having your app take 5 mins to start up), b) execute before any static method of the class is executed Instead of having them execute only when an actual object of the class is instantiated. :mad:
cheers, Chris Maunder
CodeProject.com : C++ MVP
Chris Maunder wrote:
Instead of having them execute only when an actual object of the class is instantiated.
:confused: Is that so as a rule, Chris?
class Program
{
static Program()
{
Console.WriteLine("static ctor");
}static void Main(string\[\] args) { Console.WriteLine("Main"); }}
Outputs :-
static ctor
MainRegards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blog -
Chris Maunder wrote:
Instead of having them execute only when an actual object of the class is instantiated.
:confused: Is that so as a rule, Chris?
class Program
{
static Program()
{
Console.WriteLine("static ctor");
}static void Main(string\[\] args) { Console.WriteLine("Main"); }}
Outputs :-
static ctor
MainRegards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blogBeat me to it, I was about to do a test. b/c it sure seems ludicrous that they would do that. But, sadly, I was not surprised.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
Chris Maunder wrote:
Instead of having them execute only when an actual object of the class is instantiated.
:confused: Is that so as a rule, Chris?
class Program
{
static Program()
{
Console.WriteLine("static ctor");
}static void Main(string\[\] args) { Console.WriteLine("Main"); }}
Outputs :-
static ctor
MainRegards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blogI just did a test, the static constructor is called just before a static variable is accessed, or a static method is called. So, just in time, which seems fine to me.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
Why oh why can't we just have static constructors either a) execute at App start, or (if you are picky about not having your app take 5 mins to start up), b) execute before any static method of the class is executed Instead of having them execute only when an actual object of the class is instantiated. :mad:
cheers, Chris Maunder
CodeProject.com : C++ MVP
Are you sure ? I just did some tests, and it seems to always do option (b)
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
Why oh why can't we just have static constructors either a) execute at App start, or (if you are picky about not having your app take 5 mins to start up), b) execute before any static method of the class is executed Instead of having them execute only when an actual object of the class is instantiated. :mad:
cheers, Chris Maunder
CodeProject.com : C++ MVP
-
-
Are you sure ? I just did some tests, and it seems to always do option (b)
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
To get the definitive answer when static ctor (or type initializers) do run here is the blog about it: http://geekswithblogs.net/akraus1/articles/90803.aspx Static ctors are thread safe they are normally called before any static method or field is accessed. This "normally" rule is broken in certain cases to ensure that the initialization sequence does not end up in recursion or a deadlock. Chris I supose you do have a class with statics and circular dependencies if you do not see your static ctor run before first access to your class. This is bad design ;P and should be avoided in favor of a more explicit initialization semantics like the double checked lock pattern. Yours, Alois Kraus
-
Why oh why can't we just have static constructors either a) execute at App start, or (if you are picky about not having your app take 5 mins to start up), b) execute before any static method of the class is executed Instead of having them execute only when an actual object of the class is instantiated. :mad:
cheers, Chris Maunder
CodeProject.com : C++ MVP
Now, now...Let's not go getting angry. I think there are 2 reasons. First off, they function similarly to ObjectMain in COM, so they were kinda copying that pattern. Second, and more importantly - what order would you like your objects to be called in? You could open a whole rats nest by having various static constructors referencing static members in all your different classes. That's a messy situation that's best left avoided. J
-
I just did a test, the static constructor is called just before a static variable is accessed, or a static method is called. So, just in time, which seems fine to me.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
Desktop or ASP.NET? In ASP.NET I'm running through the code again and again and the static constructor isn't being called until an object is being instantiated, even if I call a static method. Regardless: I will hark back to my C++ days and Trust No One. Explicit calls are now the order of the day.
cheers, Chris Maunder
CodeProject.com : C++ MVP
-
Why oh why can't we just have static constructors either a) execute at App start, or (if you are picky about not having your app take 5 mins to start up), b) execute before any static method of the class is executed Instead of having them execute only when an actual object of the class is instantiated. :mad:
cheers, Chris Maunder
CodeProject.com : C++ MVP
If you ask me, you're just being unmanageable. :)
Author of The Career Programmer and Unite the Tribes www.PracticalStrategyConsulting.com
-
Desktop or ASP.NET? In ASP.NET I'm running through the code again and again and the static constructor isn't being called until an object is being instantiated, even if I call a static method. Regardless: I will hark back to my C++ days and Trust No One. Explicit calls are now the order of the day.
cheers, Chris Maunder
CodeProject.com : C++ MVP
Chris Maunder wrote:
In ASP.NET I'm running through the code again and again and the static constructor isn't being called until an object is being instantiated, even if I call a static method
Did you see someone else replied about this ? It works fine for me with a basic test scenario, even in ASP.NET. So, I guess you've run into the specific problem the other poster mentioned.
Chris Maunder wrote:
Regardless: I will hark back to my C++ days and Trust No One.
I trust C++ more than I do C#.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
Desktop or ASP.NET? In ASP.NET I'm running through the code again and again and the static constructor isn't being called until an object is being instantiated, even if I call a static method. Regardless: I will hark back to my C++ days and Trust No One. Explicit calls are now the order of the day.
cheers, Chris Maunder
CodeProject.com : C++ MVP
Hi Chris, sorry to hear you cursing against C#. You are right that there is no way to initialize statics during application startup. But this was never the case even in C++ days. In dlls there is an initialization chain which ensures that during module load the statics are intialized correctly. Things are different with JITed languages since most of the code has not been compiled when the module is loaded. This implies that there is no way to get your static initialized during module load except the CLR guys provide you with a hook to call your C#DllMain. But until then there will be no way initialize all statics during module load at once. From a more distant viewpoint it might even be a good thing that there is no such function anyway. If it would be here I hear you already cursing that you want to do something before C#DllMain was called ;) Your seconds problem that the static ctor aka type initializer has not been called when you are inside a static method should not happen except in grave cirumstances when a race condition occured. Suppose two classes A and B where each of them has a static instance of the other type inside it. This was bad design in C++ and is still in C#. If you have a different scenario where this happens I would be glad to hear about it. Yours, Alois Kraus My Blog
-
Why oh why can't we just have static constructors either a) execute at App start, or (if you are picky about not having your app take 5 mins to start up), b) execute before any static method of the class is executed Instead of having them execute only when an actual object of the class is instantiated. :mad:
cheers, Chris Maunder
CodeProject.com : C++ MVP
Nah... Old age will kill you but .Net will drive you insane.:^):-D
-
Why oh why can't we just have static constructors either a) execute at App start, or (if you are picky about not having your app take 5 mins to start up), b) execute before any static method of the class is executed Instead of having them execute only when an actual object of the class is instantiated. :mad:
cheers, Chris Maunder
CodeProject.com : C++ MVP
Anyone else mentioned "Do not post programming questions (use the programming forums for that)" ? :rolleyes: