0

Possible Duplicate:
Difference between Property and Field in C# .NET 3.5+

Sample code:

public struct State
{
    private readonly byte state;

    private State (byte pState)
    {
        state = pState;
    }

    // property...

    public static State StateOne
    {
        get
        {
            return new State (1);
        }
    }

    // or...

    public static readonly State StateOne = new State (1);
}

Should I use properties or fields? Performance doesnt matter in this example.

Community
  • 1
  • 1
apocalypse
  • 5,281
  • 8
  • 41
  • 86

3 Answers3

1

Unless you are using that property as a Factory of new instances you should cache the returned "new State(1)" in a private member and return that one after the first call which would initialize it. (a Singleton)


To Clarify further:

The difference in what you wrote is that the field will always point to the same instance while the property always creates a new instance and returns it, so the property keeps creating new instances, which might not be what you want and might be a performance problem depending on the situation.

dutzu
  • 3,771
  • 9
  • 16
  • Why should I cache if this is a struct not a class? – apocalypse Jan 14 '13 at 10:24
  • 1
    makes no real difference - being a struct the value is passed around by value anyway. – Andras Zoltan Jan 14 '13 at 10:25
  • @zgnilec Like i said, it depends on what you want, do you want to keep creating instances or to return the same one and keep a reference to it? – dutzu Jan 14 '13 at 10:26
  • Structs aren't references. You can box them, but each time you do that you get a new reference. – Andras Zoltan Jan 14 '13 at 10:26
  • @AndrasZoltan So what you are saying is that (in his example) by accessing multiple times the field it's the same as accessing the getter in the property? – dutzu Jan 14 '13 at 10:28
  • yes - pretty much, okay so you can argue that there might be a small constructor overhead as the `int` is copied - and with that I do agree that a local variable might make a small difference (except the OP states performance isn't the concern) - but I believe your answer is more appropriate when the type will be a `class` and not a `struct`. With a struct, a local field and public property with an already-initialised value will be ultimately identical, because in both cases the actual struct's data will be copied, not passed by reference. – Andras Zoltan Jan 14 '13 at 10:33
  • And just to chip on your final point - there are no 'references' with structs. Two value-types are never reference-equal, but they can *be* equal. i.e. `1==1` but `!object.ReferenceEquals(1, 1)` – Andras Zoltan Jan 14 '13 at 10:42
  • @AndrasZoltan Yes, i just realized that, you are right. I was hanging on the idea that by returning new instances you might have leaks because references are left hooked in different places, but for structs there are no references, they are value-types copied as-is. 10x for clearing that up – dutzu Jan 14 '13 at 10:43
1

In my opinion, it's fields because it's the minimum you need and it's probably more readable. But realistically there's no actual difference in such a trivial case presented as in this struct given the pass-by-value semantics.

In particular - the argument for the property, with a cached local field (as on another answer here)) is completely null and void on the grounds of reference equality because, by their very definition, value types can never be reference-equal.

Andras Zoltan
  • 40,853
  • 11
  • 98
  • 156
1

I'd like using fields here instead of properties. See how MS guys did similiar work:

//String.cs
public int Length { get; }   //string has a property named Length
public static string Empty = ...    //string has a public field named Empty

Try to think "string has a public property called Empty", No, Empty is not a property of a string. Things are almost the same in your case. "State has a property called One" sounds really weired.

Cheng Chen
  • 39,413
  • 15
  • 105
  • 159