To me structs and classes look basically the same.

Whats the difference?
When would you use one and not the other?

Here are just some of the differences between a struct and a class:

• Classes are reference types and structs are value types. Since classes are reference type, a class variable can be assigned null, but we cannot assign null to a struct variable, since structs are value type.
• You will always be dealing with reference to an object ( instance ) of a class. But you will not be dealing with references to an instance of a struct, you will be dealing directly with struct
• Classes must be instantiated using the new operator, but structs can be instantiated without using the new operator.
• Classes support inheritance.But there is no inheritance for structs, (structs don't support inheritance polymorphism )
• It is not mandatory to initialize all Fields inside the constructor of a class. But all the Fields of a struct must be fully initialized inside the constructor.
• structs object is allocated in the stack, and the class object is allocated in the heap.

Class are usually for large amounts of data, whereas structs are smaller, and often used when you want to group similar data together. Use a class when object identity is more important than value. Use a struct when the value contained by an instance is more important than instance identity.

Struct variables directly contain their values, so when you pass a struct instance as a parameter, it can be more expensive than passing an instance of a reference type, due to
the copying costs.

This post has been edited by PsychoCoder: 25 Oct, 2007 - 01:43 PM

Structs exist for one, and only one, reason: to make C coders feel all warm and fuzzy. ( ref exists for probably the same reason )

The only advantage a struct offers is a functionally different memory allocation model. Should an OO programmer running managed code care? No, they shouldn't have to. However, in C a struct is really THE record type and it's used quite extensively in the Win32 API, among others.

The only possible reason to use a struct is if you have to hook into some legacy DLL. For C# programming, the things are an ugly appendix leaving confusion and crufty code in their wake.

Can you tell I don't like struct? Seriously, there are no good reasons to use them pure C# architecture. The only one you'll deal with frequently in regular C# is DateTime, and that's caused programmers more pain and suffering than daylight savings time itself.

Also,a structure cant have a parameterless constructor, and a structure is not allowed to have a destructor.

Structs are good for small data objects that deal with mathematics, like complex numbers and points in a coordinate .

But as everyone said, the biggest difference is that structs are stored on the stack and classes are on the heap. Structs also do not support any inheritance.

Ok, so if I'm catching your drifts ~ in C# use classes instead and avoid structs like the plague (quote: baavgai) unless you really really have to use them?
Or unless you need to force someone to initialize certain fields?

Isn't there a way to force someone to initialize all fields in a class?

A structure would be collection of related data, while a class would be collection of data and code which handles that data.

as said earlier , structs are stored on the stack while classes are stored on the heap.they (structs) also do not support inheritance(also said earlier).i don't agree with Baavgai saying structs should be avoided,infact in some cases of programming you are better of with structs than classes for example when displaying coordinates and doing some basic maths which do not require any methods.in these cases structs will save you resources since they wouldn't need any memory addresss to access the data (not referenced).

Yes, a class constructor can force init parameters. The initialization here refers to nulls:

Here, s is null, both i and d must have some value that's within their scope. I believe i starts with 0 and d might be DateTime.Now. (Sorry, not close to a dev box. )

That you can't have true nulls in non class types is such a bother that a NullObject design pattern is common. Such a pattern is even implicitly implemented in .NET 2.0 with constructs like DateTime ?d, which wraps d in an object for ease of processing.



Problem: in C# structs can have methods! Now how do you explain the difference to a student? Structs have grown to blur the line, which is why they're such a pain to explain.

So, the reason to use these things is the stack? They look like objects to the user, until they are parameters, at which point copies are made and values never returned. Sure, you can use ref and break your OO even more. A careless list2=list1 will behave quite different for a struct than an object. And not having null is messy.

Using the stack has to be a really big bonus to recommend a struct. But in itself it's a negative, because now I have to think about stack and heap. Even better, it's far far easier to overflow a stack. Of course, even though objects live on the heap, their privative parts will ultimately find their way to the stack for processing. Some of the use the stack argument is lost there.

In an Object Oriented environment, primitives are a required evil. Structs, on the other hand, are an unsavory, ultimately unnecessary, blemish. There are few list processing examples you might come up with which recommend a struct, but I don't believe such C hold overs can really justify the thing's existence.

i guess you will not change your mind about structs in c#.understood,everybody has his style.