|
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.
|
|
|
|
|
Thanks Senthil,
Question answered.
regards,
George
|
|
|
|
|
George_George wrote: And even if we provide a customized one, the default parameter-less one still exists.
NO.
class Program
{
static void Main(string[] args)
{
Foo foo = new Foo();
}
}
class Foo
{
public Foo(int param)
{
}
} The above code won't compile. When you provide a constructor, comoiler won't generate a default one.
|
|
|
|
|
Thanks ForumExpertOnLine!
1.
Good to learn from you value type and reference type treat this scenario differently -- whether or not the default constructor exists if we provide a customized constructor -- for value type, it exists and for reference type it does not exists. Right?
2.
Any comments to?
http://www.codeproject.com/script/Forums/View.aspx?fid=1649&msg=2598697[^]
regards,
George
|
|
|
|
|
George_George wrote: for value type, it exists and for reference type it does not exists. Right?
Yes. For structs, default parameterless constructor is created automatically. You can't write a parameterless constructor for a struct.
|
|
|
|
|
Thanks ForumExpertOnLine,
Question answered.
regards,
George
|
|
|
|
|
Hi,
I have a XML document (that I've got from an InfoPath form) and it has its namespaces.I'd like to deserialize this XML document into a type and send it to a WebService.The type has been generated when I referenced the WebService in my project.
When I try to deserialize the XML document I get a "xmlns was not expected" error thrown by XmlSerializer.
What should I do to either remove namespaces from the XML document or introduce them to XmlSerailizer so It can recognize QNames?
Regards
|
|
|
|