tags:

views:

249

answers:

7

Hi,

We have seen lots of discussion in SO regarding the class vs struct in c#. Mostly ended with conclusions saying its a heap/stack memory allocation. And recommending to use structs in small data structures.

Now I have a situation to decide the simple data store among these two choices. Currenlty in our application we have thousands of classes, just acts as simple data stores (only exposed public fields) and they passed among different modules and services.

As per my understanding, i felt its better to move ahead with struct instead classes for the performance reasons. Because these are simple data structures only act as data stores.

Before proceeding with this, i need some expert advice from the people who experiences this struggle.

  • is my understanding correct?
  • i have seen most ORMs have classes as data stores. So i doubt there should a reason to go ahead with classes instead structs. what would that be?

Cheers

RameshVel

+5  A: 

structs should be defined immutable where in classes should not. If you think your objects are going to be small and immutable you can go ahead with making them structs or else let them be classes.

this. __curious_geek
+3  A: 

I can never really seem to remember, exactly how structs are different, but they are. In subtle ways. In fact, sometimes they come and bite you.

So. Unless you know what you are doing, just stick to classes.

I know this sounds a little newbie. I know I should right now go and look up the differences and display them here - but that has already been done by others. All I'm saying is that adding a different type of objects creates a semantical burden, a bit of extra complexity that you are wise to consider carefully.

If I remember correctly, one of the biggest problem is the value semantics of structs: Passing them around will result in different objects (as they get passed by value). If you then change some field in one place, beware that in all other places the field did not get changed! That is why everyone is recommending immutability for structs!

EDIT: For the case you are describing, structs won't work!

Daren Thomas
STW
@Darren, "Passing them around will result in different objects"- is a great point... i really understand the problem now.. :)
Ramesh Vel
@Darren... got a silly doubt.. we can pass the structs as ref params.. will that solve the problem of immutability??
Ramesh Vel
it might. I wouldn't bother thinking this through, though, as this is just begging for stupid mistakes with hard to find bugs. How are you going to make sure nobody ever, *ever* forgets the ref keyword?
Daren Thomas
+2  A: 

The comment about structs being immutable is correct. And this is where it can bite you. You can define structs with field setters, but when you change a field value a new instance is created. So if you hold a reference to the old object it will still reference the old value. I don't like using mutable stucts for this reason as this can produce subtle and complex bugs (especially if you use complex compound statements).

On the other hand, there are lots of good reasons for using classes with immutable state also (think string).

Dennis Sellinger
*"when you change a field value a new instance is created"* - this line is a bit misleading IMO. For mutable structs (i.e. with field setters), you will simply change the field. Any part of code pointing to **that** struct will have it changed. For immutable structs, you will have to explicitly provide a way to construct a new instance with a different field value.
Groo
+8  A: 

I would make the choice based on the following criteria

  • reference type vs value type semantics. If 2 objects are only equal if they are the same object, it indicates reference type semantics => class. If the value of its members defines equality (e.g. 2 DateTimes are equal if both represent the same point in time even if they are 2 distinct objects), value type semantics => struct
  • Memory footprint of the object. If the object is huge and frequently allocated, making it a struct would consume the stack much faster, hence I'd rather have it as a class. On the contrary, I'd rather avoid the GC penalty for small value types; hence make them a struct.
  • can you make the object immutable? I find structs great for 'value objects' - from the DDD book.
  • Would you face some boxing-unboxing penalty based on the usage of this object? If yes, go for class.
Gishu
+1 I learned something today
Peter
+1  A: 

I remember one advice given on MSDN that struct should not be larget than 16 or 21 bytes. Looking for the link, but can't find it yet.

The main implication was that once you have a string in your data type - make it a class without thinking. Otherwise the struct shouldn't hold much.

Tomas Pajonk
String is a class, so its content is in the heap, not in the stack. If you have a string as a field of a struct, it occupies only 4 bytes in this struct (a pointer).
VladV
+2  A: 

I think you have the right idea. Structs are made to mimic data-types. They are value driven not reference based. If you look at the MSDN documentation for most of the base data classes (int, double, decimal, ect.) they are all based on structs. That being said however, structs should not be overused for that very same reason. Room to store all everything in that struct is allocated as soon as it is instantiated, where as classes just allocate room for a reference to everything inside. If the data is in small enough chunks where this is not a problem than structs are the way to go. If this is an issue go with classes. If you don't know than it might just be best to stick with what you are familiar with.

Adkins
A: 

In your case Class seems better idea ..

infant programmer