struct and class

jitendra sandu

Dear Sir, can you tell me when do i use struct and when i use class

Calla

Use a struct if you have no need for methods or to use inheritance and you only need a structure to store data (remember that a struct is passed by value and an object is passed by reference in C#).

OriginalGriff

Ignore what Calla says - a struct can indeed have methods, properties and events. In fact, there are only three real differences between a struct and a class: 1) A struct is created on the stack, not the heap. 2) A struct cannot have a parameterless constructor - it must have at least one parameter. 3) A struct is always sealed - you cannot inherit from it. The first difference is the biggie: it means that you deal with the instance directly, not via a reference. Why this is important is a bit complex, so it would be best for you to read a good book on C# as it is very important that you understand what happens properly, if you are going to use structs instead of classes. At least the authors will have experience in explaining the difference to beginners, and teh added benefit of pictures, which make things a lot easier to understand!

You should never use standby on an elephant. It always crashes when you lift the ears. - Mark Wallace C/C++ (I dont see a huge difference between them, and the 'benefits' of C++ are questionable, who needs inheritance when you have copy and paste) - fat_boy

OriginalGriff

I'm sorry, but that answer is wrong in so many ways: A struct can have methods, (and properties, and events), and can inherit from interfaces. It is true that it is automatically sealed, so you cannot inherit from a struct, but a struct can inherit if it needs to. A struct is an object, just it derives from System.ValueType which forces it to be stack allocated rather than heap. It is this that means it is passed by value rather than by reference, nothing else.

You should never use standby on an elephant. It always crashes when you lift the ears. - Mark Wallace C/C++ (I dont see a huge difference between them, and the 'benefits' of C++ are questionable, who needs inheritance when you have copy and paste) - fat_boy

Calla

Hrm.. I never said a struct couldn't have methods, properties or events (though I can understand how my reply could be interpreted like that). I was only trying to give a (simple) direction of when to use a struct and when to use a class. But maybe I was being slobby..

OriginalGriff

Calla wrote:

Use a struct if you have no need for methods or to use inheritance and you only need a structure to store data

Sounds like you can't use methods to me! :laugh: Seriously, I don't think it's fair on beginners to give information that is misleading (not that you meant to, I'm sure) - it could send them down completely the wrong path. The difference between a struct and a class is a bugger to explain unless you can see how they are reacting to the info, which is why I suggested a book!

You should never use standby on an elephant. It always crashes when you lift the ears. - Mark Wallace C/C++ (I dont see a huge difference between them, and the 'benefits' of C++ are questionable, who needs inheritance when you have copy and paste) - fat_boy

DaveyM69

Structs are value types - what that means in your situation is that it should only be used to represent a value. For example an int has one particular value lets say 1. If you need an int with the value of 2 then it must be a different int as there is no way that 1 can be 2. Therefore, once a value is set for a struct it should not be changed by a property, method or anything else. This is called immutability and something all structs should adhere to (although there are exeptions in the framework). So all properties will be readonly and any methods that normally mutate the object should return a new instance of the struct with the required values and leave the original instance intact. Also, the fields that make up a struct (must be private) should be value types themselves and should not, when combined, have a large memory footprint.

Dave

If this helped, please vote & accept answer!

Binging is like googling, it just feels dirtier. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)

Calla

OriginalGriff wrote:

Sounds like you can't use methods to me!

...or like you read the reply as the devil reads the bible ;) Seriously though, I admit it's a poor description but only as a result of trying to keep things short and provide a quick reply. I do realize you have a responsability when providing an answer to a beginner of making sure it's accurate and not misleading. :-O

Gideon Engelberth

I'm afraid your answer is also wrong. Structs are not forced to be stack allocated. The runtime simply chooses to use the stack in a limited set of circumstances just because it can. However, your statement about passing by value instead of reference is correct and points to the real distinction between structs and classes.

OriginalGriff

You are right, I'm wrong :doh: Structs (and all ValueType derived objects) can be allocated on the heap - for example they are if they are part of a class instance. If I had been involved, the only difference between a struct and a class would have been: "structs are imutable, classes are not". I personally think the "stack / heap" and "value / reference" distinction makes it harder to read code and work out what is happening: all parameters should be pass-by-reference unless otherwise specified - and yes, I do know stack allocation improves performance... But I wasn't involved, so we have to live with it... :laugh:

You should never use standby on an elephant. It always crashes when you lift the ears. - Mark Wallace C/C++ (I dont see a huge difference between them, and the 'benefits' of C++ are questionable, who needs inheritance when you have copy and paste) - fat_boy

PIEBALDconsult

It was clear enough to anyone who already knows what what you mean. :~

PIEBALDconsult

Keep it simple; don't use structs. :-D

Lost User

You want to make .NET even slower than it already is? Or would you make int/float/etc ugly special cases - in which case performance would still be impacted sometimes (but less often)

DaveyM69

OriginalGriff wrote:

structs are imutable, classes are not

Structs should be immutable but are not forced to be. System.Drawing.Size IIRC (not at a dev machine at the moment) is an example where MS haven't enforced this - both Width and Height properties are settable X| Also many structs used for P/Invoke by necessity are mutated by unmanaged code. It's a good rule to follow and will avoid major problems if used in a hash set of some description (the hash code will probably be invalid if it's mutated), but it's not set in stone. [edit] Just realized you were stating what you would have done if you were involved in the C# spec, not how it actually is! Apologies! :doh: [/edit]

Dave

If this helped, please vote & accept answer!

Binging is like googling, it just feels dirtier. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)

OriginalGriff

That's ok - I was just writing to remind you of that when I saw your edit! :laugh:

You should never use standby on an elephant. It always crashes when you lift the ears. - Mark Wallace C/C++ (I dont see a huge difference between them, and the 'benefits' of C++ are questionable, who needs inheritance when you have copy and paste) - fat_boy

Gideon Engelberth

That's an interesting hypothetical world. In the real world, if I do this:

static void Main(string[] args)
{
List<int> items = new List<int>(new int[] { 1, 2, 3, 4, 5, 1, 2, 3, 4 });

List<int> nextIndices = new List<int>();
try
{
    for (int i = 0; i < items.Count() - 1; i++)
    {

        nextIndices.Add(FindIndexAfter(items, i, toMatch => toMatch == items\[i\]));
    }
}
catch (Exception ex)
{
    Console.WriteLine(ex);
}

for (int j = 0; j < nextIndices.Count(); j++)
{
    Console.WriteLine(nextIndices\[j\]);
}

Console.WriteLine("Program complete...");
Console.ReadKey();

}

static int FindIndexAfter<T>(List<T> items, int startIndex, Func<T, bool> predicate)
{
if (startIndex < 0)
throw new ArgumentOutOfRangeException("startIndex",
"Start index cannot be negative.");
if (startIndex >= items.Count())
throw new ArgumentOutOfRangeException("startIndex",
"Start index must be less than the number of items");
startIndex++;
while (startIndex < items.Count())
{
if (predicate(items[startIndex]))
return startIndex;
startIndex++;
}

return -1;

}

I print:

5
6
7
8
-1
-1
-1
-1
Program Complete

Passing startIndex as ref (which is close to what you are suggesting as the default), I get this:

1
3
5
7
Program Complete

Since structs are just immutable classes, you now also return by reference, which would mean that you would be filling the list with references to variable i instead of the values returned by the function. I'm not going to try to simulate that sort of return, but I'm pretty sure you would end up with a list filled with items.Count() when you were done. So, now you either have to invent some "return by value" notation or do something like return new int(startIndex); Along the same line, you also now only have assignment by reference. Which means that

int i = 1;
int j = i;
j++;
Console.WriteLine(i);

now prints 2 instead of 1. Again, you would need some new syntax to specify "assign by value" instead of by reference. All in all, I just don't think "structs are just immutable classes" (and the default pass-by-reference that comes from it) would actuall