In C#, use of value types vs. reference types

My questions are:

• When should we use value types and when reference types?
• What are the advantages and disadvantages of one over other?
• What if one uses reference types everywhere? Is there any harm in it?

Please also discuss advantages and disadvantages of each one. I want to 开发者_运维技巧understand that as well.

You should use value types for small, immutable types which represent values.
Never make mutable structs.

For everything else, use reference types.

Use value types for immutables that do not have an identity of their own (a 1 is a 1), use reference types for other things.

There seems to be a lot of confusion over this, and Jon Skeet does a good job of clearing it up in his book "C# In Depth, 2nd Ed." (section 2.3).

My personal approach, which may or may not be right, is to ONLY use structs/enumerations (value types) to represent lightweight, atomic data structures that I know I'll be using frequently in some kind of logical or mathematical operations - think Point, etc.

That way I figure I can avoid the garbage collection performance penalty. However, Jon points out in that section of his book that there's no real guarantee, especially in new versions of the runtime, whether something will go on the stack at all.

So my best answer is use things like structs sparingly and be very conscious about why you're using them if you do. Watch out for premature optimization. And read that section in Jon's book if you can get your hands on a copy, because he does a good job of clarifying this whole topic.

Related: When to use struct?

http://www.albahari.com/valuevsreftypes.aspx

this is my reference on this point. I mainly use reference types tbh. IE classes and not structs. The main point that often gets said is that structs should only be used for small pieces of information. Really depends on the exact circumstances. Have a look at the .net framework in the object browser that should help, you will see what the microsoft guys have done and you can analyze why they made certain classes and structs.

Immutable value types and immutable reference types are semantically all but identical; the only differences are that reference types support reference equality checks that may or may not be meaningful, and that value types may be wrapped in a Nullable(Of T) while reference types are implicitly nullable. If a type is going to be immutable, depending how it will be used, there may be performance reasons to favor a struct or a class; structs are faster for some operations (nearly all operations, for sizes less than four bytes), while classes may bare faster for some others (especially for things larger than 16 bytes). Further, some types of operations are essentially impossible with structs.

Mutable struct types are useful, contrary to what some naysayers claim, but there are some caveats. If one has a variable that holds a reference to a mutable class object, and one does something to change that object, that change will effectively be "seen" by everything that holds a reference to that object. If one wishes to change an object without disturbing anything else, one must know that one holds the only reference to that object. Often times the only way to be sure of this is to copy all the data from the object into a new object instance, and then make the change to that new instance. By contrast, if one has a mutable struct, one can simply make whatever changes one wants without having to create a new instance.

The only real problem with mutable structs is that .net uses various abstractions to make them behave as part of the unified type system, and these abstractions may cause copies of structures to be used in places where the originals logically should be used. It's not always obvious when these substitutions may occur, and they can lead to confusing and erroneous behavior.