1

In C#, if I have the following code:

public int VarName { get; set; }

  1. Will VarName still be a value type?

  2. Will any boxing or unboxing occur?

  3. Is there any overhead for storing references relating to get / set?

Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
Payson Welch
  • 1,388
  • 2
  • 17
  • 29

4 Answers4

3

Yes, it will still be a value type.

No, there won't be any boxing or unboxing (since you're not treating it as an Object).

And no, there is no overhead since you're not storing references relating to get/set. It simply stores the int in a compiler generated backing field.

Justin Niessner
  • 242,243
  • 40
  • 408
  • 536
2

The getter and setter are actually methods and not fields. They will set a backing field of type int (that is a value type) and return that same backing field.

However the compiler (at least the Microsoft one) will optimize this code, and make the method call to the getter and setter inline, so that the performance between the property, and using a public field is the same.

It's always preferred to use a property instead of a public variable in a class. A good reason for this is that if you suddenly needs to make some validation when setting the variable, you can do so without changing any code calling the class, and it also makes it possible to only have the getter public, so that any subscriber to your class can only get the value and not set it.

Øyvind Bråthen
  • 59,338
  • 27
  • 124
  • 151
  • Thanks for the reply. so as far as setting the backing field, is it safe to say that the compiler generates IL code similar to: VarName.Get() for type safety and optimization? – Payson Welch Dec 08 '10 at 16:29
  • The IL will be different for a public field, and a property encapsulating the field, but for all practical purposes the JIT(Just-in-Time) compiler will optimize this when you execute the program to remove the method call (to the getter) and inline the field assignment without any method calls. See the accepted answer on this post: http://stackoverflow.com/questions/4043821/performance-differences-between-debug-and-release-builds to see a list of most of the JIT-optimizations done. The first one in the list is the one that is relevant for this specific issue. – Øyvind Bråthen Dec 09 '10 at 08:28
1

Will VarName still be a value type?

Yes.

Also will any boxing or unboxing occur?

No, because there's no conversion between a reference type and a value type.

Is there any overhead for storing references relating to get / set?

No. The C# compiler automagically generates optimized get and set methods, which do nothing but retrieve and set, respectively, the value of a compiler generated variable. It's generally better to expose variables as properties rather than public fields so that things like data binding work right, and just as a general best practice.

Bob Black
  • 2,375
  • 2
  • 18
  • 26
0

yes , it will , but if it is a property of a class , it will go on heap and also no boxing and unboxing will occure until you explicitly do it in your code.

TalentTuner
  • 17,262
  • 5
  • 38
  • 63