I know something about struct type. But I can't understand: what is it for? when have I use it? Classes, simple value-types and enums - that's all that I need.
Any suggestions?
UPD: PLEASE! Don't tell me that struct is in the stack (I know this :). What struct is for?
MSDN provdies a guide : Choosing Between Classes and Structures
Youcan use structs when you want a "class" with value (rather than reference) semantics.
If you don't know why you need it, you probably don't.
struct is a value type rather than a reference type. If you don't know what that means, then you probably aren't going to need it.
Simple value types are best implemented via a struct.
Struct Usage Guidelines
It is recommended that you use a struct for types that meet any of the following criteria:
* Act like primitive types. * Have an instance size under 16 bytes. * Are immutable. * Value semantics are desirable.
You must also understand that a class instance is allocated on the heap. A struct -is a vallue type- and is allocated on the stack.
Example: Say you want a data type to represent Coordinates at X Y Z. You don't really need any functionality, only three variables. A struct would be good for this, a class may be overkill.
You choose a struct if you want value-type semantics. You choose a class if you want reference-type semantics. All other concerns are secondary to this one.
First you must understand the difference between value-type and reference type. I will assume since you said to skip that part that you understand what it is.
Struct is a value-type and you get all of the privileges that you would get working with a value-type.
Structs are passed around by value. When you do something like
DateTime time = new DateTime(); DateTime newTime = time; // you are not referencing time // instead you have created a new instance
Structs are NOT lightweight classes they may have many methods, just look at DateTime struct.
Structs maybe lighter in performance, but not all the time. Consider passing a large struct to a method. Because structs are value-types each time you pass one into a method a new instance of the struct is created, hence copying the struct each time. If you have a fairly large struct this will be a much larger performance hit.
You may have to occasionally box and unbox structs, since they are value types.
In short, use a struct to represent an atomic value in memory.
Things that should be a struct (because they are values):
struct Colorstruct Pointstruct Rectanglestruct GLVertex (contains location, color, normal and texcoord)struct DateTimeThings that should be a class (because they are things to which you refer):
class RandomGeneratorclass Socketclass Threadclass WindowWhy? Consider the following code.
class Button
{
public Point Location { get; set; }
}
class Program
{
public static void Main()
{
var button = Util.GetButtonFromSomewhere();
var location = button.Location;
Util.DrawText("one", location);
location.Y += 50;
Util.DrawText("two", location);
location.Y += 50;
Util.DrawText("three", location);
}
}
This will draw 3 text labels, vertically aligned. But if Point is a class, this will also move the button, which is really unexpected: var location = button.Location feels like it should copy a value, and not a reference! In other words, we think of Point as a value type and not a reference type. "value" here is used in the mathematical sense of value. Consider the number 5, it's an abstract object "somewhere out there", you just "refer" to it. Similarly, a Point simply is. It doesn't reside anywhere, we can't change it. Therefore we choose to make it a struct, so it has the semantics users expect.
On the other hand, we could have class Button { public Window Parent { get; set; } }. Here, Parent is an entity, so we represent it with a reference type - Window. It may make sense to use code like myButton.Parent.Redraw();. So Window should be a class.
So far so good. But all this probably sounds too vague to you. How do you really decide if something "feels" like a reference or a value? My rule of thumb is simple:
What should Foo a = b; a.Mutate(); do?
Use the principle of least surprise here.
structs are for objects that represent something whose identity is defined by the values stored in it's properties rather than by an Id or key. These are called "Value types" as opposed tyo objects called "Entity Types", whose identity persists over time and is not dependant on the values of the properties of the object.
As an example, a Person class (an Entity) has an identity that persists from one session to another, even from year to year, in spite of how the Person's address, phone number, employer, etc might change from one instance to another. If you inadvertently have two instances of a Person class in memory at the same time, which represent the same individual/entity, then it is important that they have the same values for their properties.
A CalendarMonth object otoh, (a value type) only has identity defined by the value which specifies which calendar month it is... no matter how many instances of "March 2009" you might be using, they are all interchangeable and equivilent. Another example might be an object representing a FiscalYear designation in a tax program. A great example is an address object. (Not talking here about the asociation of an address with a person or a business, or any other entity, but just the address itself). Changing just about any property of an address makes it a different address. Once you create an address object in memory, it is equivilent and interchangeable with every other address object that has the same properties. This is why these value types should generally be immutable. When you need one, create a new one with the property value(s) you need, and throw it away when you're done using it.
In reality, I think struct is an legacy from C. I do not think we MUST use it in any condition. Perhaps sometime you feel that leaving something on stack rather than on heap is more efficient; but as Java/C# never takes efficient as its first stand, so just neglect it:) That's my opinion.