|
Hello everyone,
From the IL for the following code, seems there is default constructor for both value and reference types which accepts null argument? Are they added by CLR directly (from .locals init IL statement)?
class Program
{
struct Foo
{
int abc;
}
class Goo
{
public int abc;
}
static void Main(string[] args)
{
Foo f;
Goo g;
return;
}
}
.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
.maxstack 0
.locals init (
[0] valuetype TestStruct1.Program/Foo f,
[1] class TestStruct1.Program/Goo g)
L_0000: nop
L_0001: br.s L_0003
L_0003: ret
}
thanks in advance,
George
|
|
|
|
|
Yes, according to the spec[^].
"All value types implicitly declare a public parameterless instance constructor called the default constructor."
|
|
|
|
|
Thanks Senthil,
1. For value type, even if we provide a customized constructor, there is also the default one (co-exist with customized one)?
2. For reference type, there is also a default constructor even if we provide a customized one (co-exist with default one)?
regards,
George
|
|
|
|
|
George_George wrote: For value type, even if we provide a customized constructor, there is also the default one (co-exist with customized one)?
NO
George_George wrote: For reference type, there is also a default constructor even if we provide a customized one (co-exist with default one)?
NO
|
|
|
|
|
ForumExpertOnLine wrote: George_George wrote:
For value type, even if we provide a customized constructor, there is also the default one (co-exist with customized one)?
NO
Wrong - the default constructor exists, whether you create a overloaded one or not.
struct S
{
int x;
public S(int x)
{
this.x = x;
}
public int X
{
get { return x; }
}
}
class Program
{
static void Main(string[] args)
{
S s = new S();
Console.WriteLine(s.X);
}
}
|
|
|
|
|
Ahh - I didn't noticed that. Thanks for pointing it.
|
|
|
|
|
Great Senthil!
I think the conclusions are, could you help to confirm? Correct?
1. For value type, whether or not we provide a customized constructor, there is a default one (co-exist with customized one).
2. For reference type, there is also a default constructor, whether or not we provide a customized one (co-exist with default one).
regards,
George
|
|
|
|
|
George_George wrote: 1. For value type, whether or not we provide a customized constructor, there is a default one (co-exist with customized one).
No, but you can always create value types without calling a constructor.
If you for example declare an array of value types, the array will be filled with the default value of the value type (which is all members set to zero).
George_George wrote: 2. For reference type, there is also a default constructor, whether or not we provide a customized one (co-exist with default one).
No, if you create a custom constructor, there is no default constructor automatically created for you.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
I think for value types, only the memory space is reserved, you can not access the fields if you only "create" them with default constructor and not initializing to them. Right?
regards,
George
|
|
|
|
|
George_George wrote: I think for value types, only the memory space is reserved, you can not access the fields if you only "create" them with default constructor and not initializing to them. Right?
That is only if you declare a value type as a local variable in a method. If you declare a value type as an instance member in a class or declare an array of value types, they are initialised (set to all zero).
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
I have a further question. For code like this,
struct Foo
{
public int abc;
}
Is there a default constructor generated which is parameter-less? From IL code, I can not see. Any comments?
regards,
George
|
|
|
|
|
George_George wrote: For code like this,
struct Foo
{
public int abc;
}
Is there a default constructor generated which is parameter-less?
No, the compiler doesn't create a parameterless constructor. It exists in theory, and you can use it, but the compiler translates that into simply clearing all members of the structure.
This code:
Foo x = new Foo();
compiles into this IL code:
L_0000: ldloca.s x<br />
L_0002: initobj Foo
The initobj instruction sets the bytes to zero in the memory area used by the structure.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Great Guffa!
Question answered.
regards,
George
|
|
|
|
|
Guffa wrote: George_George wrote:
1. For value type, whether or not we provide a customized constructor, there is a default one (co-exist with customized one).
No,
Actually yes, there is always the default parameterless constructor, regardless of whether you overload it or not.
|
|
|
|
|
S. Senthil Kumar wrote: Actually yes, there is always the default parameterless constructor, regardless of whether you overload it or not.
Yes, in theory the value type has a parameterless constructor. It never exists as an actual method.
This source code:
int x = new int();
actually results in this code being created by the compiler:
int x = 0;
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
George_George wrote:
1. For value type, even if we provide a customized constructor, there is also the default one (co-exist with customized one)?
Yes. Read the spec[^] again.
George_George wrote: 2. For reference type, there is also a default constructor even if we provide a customized one (co-exist with default one)?
Read the spec (http://www.jaggersoft.com/csharp_standard/8.7.8.htm[^]) again.
"If no instance constructor is supplied for a class, then an empty one with no parameters is automatically provided."
|
|
|
|
|
Thanks Senthil,
S. Senthil Kumar wrote: "If no instance constructor is supplied for a class, then an empty one with no parameters is automatically provided."
And even if we provide a customized one, the default parameter-less one still exists.
regards,
George
|
|
|
|
|
George_George wrote: And even if we provide a customized one, the default parameter-less one still exists.
Huh? You do realize that statement directly contradicts the spec?
Try compiling this
class S
{
int x;
public S(int x)
{
this.x = x;
}
public int X
{
get { return x; }
}
}
class Program
{
static void Main(string[] args)
{
S s = new S();
Console.WriteLine(s.X);
}
}
|
|
|
|
|
Sorry, Senthil! It will not compile, my mistake to understand the statement.
So, for statement like below, the memory for new instance of abc is actually allocated even if we do not use new + constructor explicitly. But for reference type, without using new, no instances' space are allocated. Correct?
StructValueType abc;
regards,
George
|
|
|
|
|
George_George wrote: the memory for new instance of abc is actually allocated even if we do not use new + constructor explicitly
George_George wrote: StructValueType abc;
If you use abc before initializing, your code won't compile. Value types also need to be initialized.
|
|
|
|
|
Thanks ForumExpertOnLine,
I agree. I mean the memory space is allocated, right?
regards,
George
|
|
|
|
|
George_George wrote: So, for statement like below, the memory for new instance of abc is actually allocated even if we do not use new + constructor explicitly. But for reference type, without using new, no instances' space are allocated. Correct?
Depends on what you call memory? In both cases, stack space will be reserved for holding the local variable. In the case of reference types, space on the heap will not be allocated until you call new. That doesn't apply for value types obviously, so stack space will be reserved right away.
|
|
|
|
|
S. Senthil Kumar wrote: so stack space will be reserved right away.
I doubt. AFAIK, it depends on the context where the struct variable is used. If it is declared with a instance field, I guess it will be kept in the heap along with the instance. I am not sure though. This[^] is worth reading.
|
|
|
|
|
Good point, do you have any ways to test or prove whether memory is allocated or not for value type variables used as a member field for a reference type?
regards,
George
|
|
|
|
|
Which is why I said "In both cases, stack space will be reserved for holding the local variable.
|
|
|
|