Does the automatic property of C# 3.0 completely replace the filed?
I mean,I can directly use the property instead of filed as property serves as private backing field.(sorry,I understand like that only).
int a;
public int A
{
get;set;
}
+6
A:
Yes, the automatic property has its own holding field.
When you define an automatic property, the compiler will create the necessary backing field. It is not available as a field from regular code, but it is there and you can access it via reflection if you really need it.
Please see this guide for more info: http://msdn.microsoft.com/en-us/library/bb384054.aspx
Brian Rasmussen
2009-11-14 19:09:09
Sorry Nescio answered first.So i ticked his answer.
2009-11-14 19:11:07
No problem. You pick the answer you prefer.
Brian Rasmussen
2009-11-14 19:11:38
:) thanks for your Magnanimity
2009-11-14 19:13:00
I disagree that it is "now available as a field" - that would suggest you could pass it by reference. It's a property, with its own private backing field that nothing else can access.
Jon Skeet
2009-11-14 19:20:47
@Jon, you're right. Stupid typo. I meant to say "not available". Thanks.
Brian Rasmussen
2009-11-14 19:22:37
Ah, that makes a lot more sense :)
Jon Skeet
2009-11-14 19:31:17
+6
A:
When you access the property from code - whether inside or outside the class - it is always accessed as a property. In most cases, this is unimportant - but it does mean that you can't pass it by reference, which you would be able to do if it were a field.
The only piece of code which accesses the backing field directly (reflection aside) is the property itself.
It is a property, pure and simple. It isn't available as a field - it's available as a property. The C# compiler doesn't replace accesses to it with field accesses. Accesses to it are always property accesses. It may well be inlined by the JIT compiler of course, but that's nothing special. As far as the CLR is concerned it's just a normal property (which happens to have the [CompilerGenerated] attribute applied to it).
But to answer your original question - yes, the automatic property means you don't need to declare the backing field yourself. Effectively, this:
public int Foo { get; set; }
is translated into
private int <>Foo; // Or some other unspeakable name
public int Foo
{
get { return <>Foo; }
set { <>Foo = value; }
}
You cannot access the generated field directly in C# code, as it has an unspeakable name. You'll see it's present if you examine the type with reflection though - the CLR doesn't distinguish between an automatically implemented property and a "normal" one.
Jon Skeet
2009-11-14 19:18:53
you mean to say when using property i can not do (ref A) if A were a property .right?
2009-11-14 19:23:07
Please see my comment. "now" should have been "not" (otherwise the bit about reflection is a bit redundant).
Brian Rasmussen
2009-11-14 19:26:28
Normally i have seen the notation Foo<int> ... But what does private int<> Foo means? I mean angle bracket after int (i.e) int<> and <>Foo ..?
2009-11-14 19:34:58
It's the name of the field: `<>Foo`. The C# compiler deliberately uses angle brackets to make the name "unspeakable" - i.e. one that isn't actually valid in C#, but is fine for the CLR. This means there's guaranteed not to be a collision with a "normal" member, and you won't be able to access it in code. The exact name is implementation-specific though - don't count on it being called `<>` followed by the property name. (I haven't even checked whether it happens to do that now - but it'll be something like that.)
Jon Skeet
2009-11-14 19:49:28
A:
There is some compiler magic involved, such as with delegates, and so. You can see it as if the compiler takes charge of creating the necessary code that otherwise you would have to type in explicitly.
Simón
2009-11-14 19:19:40