Package methods in struct

Is it common practice to package methods with other elements(string-s, int-s, float-s, array-s...) of struct?

Than struct acts as a class or is acting similar to class and that have no sense to me? I am new to OOP :).

In C#, both classes and structs are understood to be used in the same way: containing methods, properties and variables. The technical difference is that all structs are value types while classes are reference types.

If in doubt, use class. That's easier and less misunderstandings and side effects for the start.

Quote:

---

Originally Posted by nvoigt

In C#, both classes and structs are understood to be used in the same way: containing methods, properties and variables. The technical difference is that all structs are value types while classes are reference types.

If in doubt, use class. That's easier and less misunderstandings and side effects for the start.

---

Thanks

What might sound odd is that structs are actually more expensive than classes in C#. You should prefer class over struct unless your object does not change or is immutable. You should never use a struct when the struct is not constant. This can lead to some nasty hard to find errors when structs are re-used and yet their contents are not reset.

Microsoft's own advice follows:

Do not define a structure unless the type has all of the following characteristics:
1.It logically represents a single value, similar to primitive types (integer, double, and so on).
2.It has an instance size smaller than 16 bytes.
3.It is immutable.
4.It will not have to be boxed frequently.


However note that in the XNA SDK and in some portions of .NET they violate these rules.

http://www.dotnetperls.com/struct

Quote:

---

Originally Posted by VirtualAce

However note that in the XNA SDK and in some portions of .NET they violate these rules.

---

Mostly because that advice list should be tempered. If followed to the letter, it can lead to classes that are performant, when structs could be used. A possible scenario is an hexagon in a game map.

Code:

---

struct Hexagon
{
    public int X { get; private set; }
    public int Y { get; private set; }
    public TerrainType Terrain { get; private set; } // an enum
    public bool HasSettlement { get; set; }
    public bool HasRoad { get; set; }

    public List<Hexagon> GetNeighboors() { ... }

    public override bool Equals(object obj) { ... }
    public static bool operator ==(Hexagon hex1, Hexagon hex2) { ... }
    public static bool operator !=(Hexagon hex1, Hexagon hex2) { ... }
}

---

That struct violates all of the items in Microsoft's advice list. And yet it can have maybe ~62,000 instances at one time (in a 250x250 map) and will almost exclusively be used inside a generic container. probably a List<Hexagon> representing the map.

If we follow Microsoft advice we will be putting a great load on the garbage collector, which too can greatly affect performance. A concern if that List is going to be recreated numerous times. Probably much better to keep Hexagon as a struct since the generic container will ensure its contents remain in the stack and are thus much more quickly freed from memory. But on the other hand, if that List is going to persist during the whole lifetime of the application, it should be a mistake not to serve those Hexagon instances to the heap and thus change it to a class.

What I'm saying is that we should avoid going from 8 to 88. From believing that structs were lightweight instances (which was indeed a misconception) to believing structs are more performant (which is also a misconception). We will often get into tough situations where we will not be sure what to do and bootlenecks rarely are were we expect them to be, so the best option is to do some extensive profiling and chose based on the individual requirements of the situation. If there's a tradeoff (almost always there is), make a decision based on what is that exactly we want to preserve; memory or performance.