0

Since C# 3.0 there is the new syntax to autogenerate the instance variable from a propertie:

public string Foo { get; set; }

But there is no way to access the underlying backing field. So I don't really see the point of it because declaring the same instance variable would produce the same effect without the overhead of calling the "getter" and "setter".

public string Foo;

Declaring the property like:

public string Foo { get; }

or

public string Foo { set; }

is totally useless since we are not able to write resp. read the content of the field.

Does someone have a good explanation for why in C# they have put all this effort to introduce this syntactic sugar?

EDIT: People seems to think that I am confusing field and properties so let me clarify what I have said.

If you are using a property with auto generate field:

public string Foo { get; set; }

Then there is no point to it, since whenever you access the properties there is the overhead call to the get_Foo() "getter" every time you are accessing the properties and since your aren't doing anything particular in the the "getter" there is not mush interest of creating this property. Creating the field would have been exactly the same and it is mush faster (optimization wise).

Thanks

mathk
  • 7,353
  • 6
  • 41
  • 70
  • 1
    What overhead are you talking about? – CodesInChaos Jul 25 '12 at 13:51
  • What CodesInChaos just said: I doubt the compiler actually generates functions for getters and setters, and if it does they're most likely inlined. –  Jul 25 '12 at 14:06
  • Unless you declare your property virtual in this case you could have some inline caching but you still suffer a branch overhead. – mathk Jul 25 '12 at 14:17
  • possible duplicate of [Auto-implemented getters and setters vs. public fields](http://stackoverflow.com/questions/111461/auto-implemented-getters-and-setters-vs-public-fields) – nawfal Jul 17 '14 at 20:33

5 Answers5

4

public string Foo { get; set; } defines a property.
public string Foo; defines a field.

They are different things. And the former is very convenient when you actually want a property and not a field.

As for accessing, you can define different access levels:

public string Foo { get; private set; }

See also Difference between Property and Field in C# 3.0+

As for your edit, what you are saying only makes sense if:

  1. You are 100% sure that your property accessors will never contain any actual logic.
  2. You are 100% sure that your field will never be data bound.

If any of the above is not true, then you need to define a property, even if that property seems like an empty stub.
Then, when later you decide to add logic to the accessors, you will not break all those clients that rely on your field being a field.
And if your class may be data bound, you need a property right away, as the data binding mechanisms ignore fields.

Community
  • 1
  • 1
GSerg
  • 71,102
  • 17
  • 141
  • 299
3
public string Foo;

Is a field.

public string Foo { get; set; }

Is a propery. They aren't the same thing, which has been discussed before. One of the mainly propagated advantages is the access control: get; private set; is used quite often as an example.

But there is no way to access the underlying backing field.

Yes there is, by calling the getter. Use [this.]Propertyname when you want to access it locally.

public string Foo { get; }

and

public string Foo { set; }

Will give you compiler errors, since you have to implement both get and set.

Community
  • 1
  • 1
CodeCaster
  • 131,656
  • 19
  • 190
  • 236
  • Ok I was not aware of the `get; private set; ` and no I am not confuse between feild and property see my edit. Anyway I upvote your response since it answer to my question. – mathk Jul 25 '12 at 14:08
  • Btw is it legal to define `protected string Foo { public get; set; }` ? – mathk Jul 25 '12 at 14:12
  • 1
    @mathk No, accessibility must be more restrictive if you are changing it in the get / set part. – Adam Houldsworth Jul 25 '12 at 14:12
  • @mathk as for your edit: don't get into the micro-optimalization road, it leads to nowhere. – CodeCaster Jul 25 '12 at 14:13
  • @AdamHouldsworth Ok I see it is grammatically correct since it is most probably a context free grammar. I really wouldn't like to write a compiler for C#; so many bodgy rules to enforce. :S – mathk Jul 25 '12 at 14:15
2

The point of it is to make the code more concise and give you less to type.

In your example:

public string Foo;

Is a field and isn't the same as a property:

public string Foo { get; set; }

So the auto-property syntax has a use and is somewhat equivalent to:

private string _foo;
public string Foo { get { return _foo; } set { _foo = value; } }

However it doesn't create nice names, it uses safe names that would be invalid in C# (but are valid in IL).

Property overhead, though technically possible, is usually ironed out by the JIT into direct field access.

Properties are also usually the target for most data-binding frameworks. In reflection, a property differs from a field. WPF / WinForms data binding uses properties (not public fields). Most properties use a backing field to store the data. The trade-off is that when in the class, you use the property still as opposed to using the backing field. In practice, on release-optimized code, the performance is exactly the same as the JIT resolves them into exactly the same thing.

Adam Houldsworth
  • 60,104
  • 9
  • 137
  • 177
  • Of course it is not the same it is just awkward to do `public string Foo { get; set; }` see my edit. – mathk Jul 25 '12 at 14:05
  • Yes the JIT would inline the call and that would make no difference, unless it is a virtual property... – mathk Jul 25 '12 at 14:31
  • @mathk But if it's a virtual property it'd be there for a reason, good luck with a virtual field :-) – Adam Houldsworth Jul 25 '12 at 14:35
  • @mathk You cannot have virtual fields. I was basically saying that your point on no in-lining with virtual properties is moot because they'd be virtual for a reason and you wouldn't be able to replicate the idea with fields. – Adam Houldsworth Jul 25 '12 at 14:40
  • Oh yes of course but I was speaking of virtual property not virtual field. Anyway "virtual field" does not make any sens. – mathk Jul 25 '12 at 14:42
  • @mathk Never mind, we are getting cross wires. I know what you were referring to. – Adam Houldsworth Jul 25 '12 at 14:44
2

By itself it's pointless, but you can do things like this:

public string Foo { private set; get; }

Which has a lot more value.

Also properties and fields are not the same things.

ilivewithian
  • 18,642
  • 19
  • 93
  • 158
  • I am aware of filed not being the same as property see my edit. – mathk Jul 25 '12 at 14:08
  • 1
    "By itself it's pointless" ? I beg to differ, I much prefer typing `public string Name { get; set; }` to the alternative if I can get away with it. – Adam Houldsworth Jul 25 '12 at 14:10
  • @AdamHouldsworth I understand what you mean adam but I personaly don't think that adding this bit of complexity in the grammar worth the effort. Unless you let me access the backing filed in the class. For instance I would like to have the backing field being private or protected. It could be base on a convention like _Name or you name it. – mathk Jul 25 '12 at 14:59
  • @mathk Backing fields are sometimes referred to as the "plumbing" of properties. Abstracting the plumbing is always a goal in programming as it enables you to work more effectively. The compiler already does this for us in places (`lock`, `using`, `foreach`, `async`). Properties have many uses and most of the time the performance difference is trivial to non-existent. A downside of old-style properties was needing to plumb the backing field where I knew I wanted a public property. They allow you to change the access mods on get and set `public string Foo { get; private set; }`. – Adam Houldsworth Jul 25 '12 at 15:10
  • Yea now that you recall that visibility can be modify I agree – mathk Jul 25 '12 at 15:20
  • It is pointless, `public string Foo { set; }` has no value. You can set it, but never retrieve the value anywhere. Not even in the declaring class. – ilivewithian Jul 26 '12 at 08:12
0

It makes defining properties faster and the code cleaner. If you don't need a property then don't define one - but I would recommend against public fields. You can make the property private and accessing it doesn't do anything more than returning the IL defined field. Further, if you need to do some work in the get or set then you'll have to define a backing value somehow, whether that be a field or some inherited member.

Mike Perrenoud
  • 63,395
  • 23
  • 143
  • 222