Click here to Skip to main content
15,031,162 members
Please Sign up or sign in to vote.
3.00/5 (1 vote)
See more:
please answer the question above for any version of c#.
Varun Sareen 29-Feb-12 0:43am
always search google first dear friend

Although the CLR allows it, C# does not allow structs to have a default parameter less constructor. The reason is that, for a value type, compilers by default neither generate a default constructor, nor do they generate a call to the default constructor. So, even if you happened to define a default constructor, it will not be called and that will only confuse you. To avoid such problems, the C# compiler disallows definition of a default constructor by the user. And because it doesn't generate a default constructor, you can't initialize fields when defining them.

Ref:- Why must struct constructors have at least one argument[^]

The .NET Common Language Runtime (CLR) does not guarantee that parameterless constructors will be called. If structs were permitted to have default, parameterless constructors, the implication would be that default constructors would always be called. Yet, the CLR makes no such guarantee.

For instance, an array of value types will be initialized to the initial values of its members—i.e., zero for number type primitive members, null for reference types, and so forth—and not to the values provided in a default constructor. This feature makes structs perform better; because, constructor code need not be called.

So, requiring that a constructor contain a minimum of one parameter reduces the possibility that a constructor will be defined which is expected to be called every time the struct type is built.

Helpful links:-[^][^]
Pretty good job. However, believe or not, I have an alternative opinion.
Espen Harlinn 29-Feb-12 15:05pm
Varun Sareen 1-Mar-12 1:50am
thanks espen
In my strong opinion, the only really valid answer will be: because creators of .NET decided to design it this way. (Did Anders Hejlsberg made a decision?)

Not that I say that the decision is not good. It's quite good, at least good enough. I just say, that I am sure that some other reasonable decisions are possible, and it's not possible to say that one of them is absolutely the best. I am well familiar with variety of constructor rules in a number of object-oriented languages (including .NET and C# predecessor, Delphi; with architecture created when Anders Hejlsberg was a chief architect in Borland), and I can tell that some syntax and semantic rules are different and not as good as in .NET, but some are different and at least not worse than that of .NET.

In view of this, all the explanations found in many source, including those explained or referenced by Varun, are somewhat funny. First, they look reasonable. Some arguments emphasize the real value of the rules under discussion. The only problem is: they do not proof anything; they just illustrate the well known phenomenon: many people are very skilled to adjust reasoning to the know fact.


I did not proof anything, but I need to illustrate that at least one argument is logically imperfect. Let's pick this one:
Varun Sareen wrote:
The .NET Common Language Runtime (CLR) does not guarantee that parameterless constructors will be called.
First, this statement is simply not correct. A class always have either implicit parameterless constructor unless an explicit constructor is defined. An explicit constructor is semantically equivalent to the constructor with empty body. In this way, it is semantically not important if it is called or not, but the whole chain of inherited constructors should be called anyway. As to the explicit parameterless constructor, it is guaranteed to be called.

In this way, the quoted statement is not true or makes no sense for class constructors. But does it make sense for parameterless struct constructors? No, because the syntax does not allow such constructors anyway.

Here is the example of circular "proof". The speculation goes: parameterless constructors are not allowed by the syntax, because if they were allowed, their call would not be guaranteed. But why the decision "not to guarantee a call the a parameterless struct constructors" would be made? This is a purely speculative consideration.


With all my respect to those authors really understanding software development: this is the phenomenon which explains the nature of superstition.

Varun Sareen 29-Feb-12 1:14am
I am not able to get you sir. Please elaborate what you want to say?
Just did, on just one item, for example. Please don't rush -- it takes some logical thinking...
Espen Harlinn 29-Feb-12 15:06pm
Sergey Alexandrovich Kryukov 29-Feb-12 16:44pm
Thank you, Espen.
I would not doubt that you, as a person knowledgeable in Delphi and other OO languages/systems, would understand it properly. :-)
Espen Harlinn 29-Feb-12 16:45pm
Thank you very much Sergey :-D

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900