7

Possible Duplicate:
Difference between Property and Field in C#

I thought that basic properties ({ get; set; }) where the same as public fields, with only the advantage of being able to change them without breaking binary compatibility. Following the answer I got here https://stackoverflow.com/a/8735303/331785, I found out there is also a disadvantage to properties. They cannot be accessed by reference if they are of a value type. Why is this, and what other differences are there?

Community
  • 1
  • 1
Baruch
  • 20,590
  • 28
  • 126
  • 201
  • here you have the answer: http://stackoverflow.com/questions/653536/difference-between-property-and-field-in-c-sharp – Dipu Raj Jan 07 '12 at 21:18
  • 5
    That's a fallacy. Properties cannot be accessed by reference, full stop. You've made the common mistake of confusing reference-passing with reference types. – Noldorin Jan 07 '12 at 21:18
  • 1
    That's to say, the reference of a reference type is passed by value by default. Passing by reference is always done with the `ref` or `out` keyword, for both reference and value types. – diggingforfire Jan 07 '12 at 21:28
  • @DipuRaj I feel this question is not an exact duplicate, as it is asking why the mentioned behavior happens, which that question does not. – Baruch Jan 08 '12 at 07:07

2 Answers2

14

I found out there is also a disadvantage to properties. They cannot be accessed by reference if they are of a value type. Why is this

Because under the covers, a property is just a method. If you look at the IL, you'll see methods like get_PropertyName and set_PropertyName. The problem with that is in order to support working with references, you would need to be able to return a reference for a method.

public ref T MyProperty
{
    get
    {
         return ref _underlyingField;
    }
}

Update: Starting in C# 7.0, this is possible using the syntax describe above.

Remainder of previous answer:

This of course, is something entirely possible in the CLR; but not exposed by the C# language.

Though it is possible, the CLR needs some tweaks to keep it as verifiable. The syntax for the property would have to support it to.

However, is any of that useful? As you stated, a field can do it. If you need it; use a field. Supporting it would take a lot of work. There are probably a very few cases where it is appropriate; and would create many cases where just using a field might have been better in the first place.

vcsjones
  • 138,677
  • 31
  • 291
  • 286
4

Properties are just sugar-coating syntax for a getX() and setX() method. It looks and acts like a field, but it's really just two methods. The reason why the auto-property was added was to avoid the repetition of having to create a field and creating a standard getter and setter for the property, and to make it much simpler to allow changing the implementation without changing the interface.

The reason they can't be accessed by reference if they are a value type is because value types are generally on the stack and because you're just calling a method. The getter in the property has to be called and the returned value has to be pushed on the stack before it can be referenced.

Robert Rouhani
  • 14,512
  • 6
  • 44
  • 59
  • 6
    -1 for propagating the myth of value types being on the stack (even with the "generally"). If the property (or field) is of a class, it *won't* be on the stack. – Jon Skeet Jan 07 '12 at 21:23
  • @JonSkeet I think he's talking about the return value of the getter, which will first end up in a register, and then probably on the stack so it gets an address that can be referenced. – CodesInChaos Jan 07 '12 at 21:27