Do I need to create a struct?

Saksida Bojan

why Class? Shouldn't struct be enough? I Would use struct instead class. Because you do not need to hold any Function only data

N a v a n e e t h

Saksida Bojan wrote:

I Would use struct instead class. Because you do not need to hold any Function only data

It is correct in C++ but not in C#. A struct in C++ is mainly used for POD types and in C#, you hardly write structs. You write it only when you need value semantics or you need to communicate with legacy APIs.

Best wishes, Navaneeth

Saksida Bojan

Is there performance drop? I use a lot of Struct in some of mine programs when I needed to hold a lot of Data structure within array (Not using PInvoke or accessing COM object). Is it better to use struct or class?

Luc Pattyn

arrays in C# are homogeneous, they can't hold different types, unless you declare them to hold a common type (in the extreme: object) which isn't a good idea. Create your own element type and keep it a one-dimensional array; in simple cases you might be well of by using a Dictionary (requires unique keys). :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages

Keith Barrow

You might, under certain circumstances use more memory. See http://msdn.microsoft.com/en-us/library/ah19swz4(VS.71).aspx[^] The things to note are (Quotes directly from above): 1) Struct are value types. Classes are reference types. 2) Structs have no inheritence (other than object). 3) "The struct type is suitable for representing lightweight objects such as Point [e.g. a Cartesian Co-ordinate]" 4) "Unless you need reference type semantics, a class that is smaller than 16 bytes may be more efficiently handled by the system as a struct." C# is very different to c++ in this matter, I've been developing C# for about 8 years now, and have never needed a struct (though I have used them from 3rd party stuff).

CCC solved so far: 2 (including a Hard One!) 37!?!! - Randall, Clerks

bbranded

Is there a performance hit when utilizing a List versus a class[array] (and dynamically sizing this array)?

Keith Barrow

Both are held on the heap, so I don't think there won't be much of a performance hit, however if performance is an issue, you could benchmark for yourself. Generally, IMO, unless you have massive arrays or massive objects performance has never been a worry and even if this is the case good design normally mitigates againt this. Modern machines are fast and have plenty of memory (even if this is restricted by the .net framework) so code readabilty is more of a factor in my experience (this would definately go down with an array that needs resizing). I'm not saying that performance shouldn't be considered, I just think that getting clean code first is better, then run the optimizers over the code, and if you see any bottlenecks really work at those, optimizing too soon (which often equals unecessarilty) really wrecks good code. Additionally, if the array is frequently resized, this can use up resources as the array is copied and re-sized (and hence my benchmarking suggestion above).

CCC solved so far: 2 (including a Hard One!) 37!?!! - Randall, Clerks

bbranded

I agree with your ideology. Thanks for explaining. When an array is re-sized, the data is actually copied/recreated? Are you sure about this?

Keith Barrow

Due to the way arrays are implemented they cannot directly resized. Array.Resize[^] provides resize functionality, but it actually does a copy underneath (as if you created an array of the new size and copied the items across) so the array instance actually changes.

CCC solved so far: 2 (including a Hard One!) 37!?!! - Randall, Clerks

bbranded

Thanks for your reply. This hit on performance (array.resize()) is less than the (probable) lower performance of a List<>? However, if array.resize() was never called, an array would be more optimal?

Keith Barrow

No (or not much) to the first, yes to the second. It really depends upon what you are doing to determine which is most efficient, and that can only be done through testing. If my memory serves, in earlier versions of the famework (2.0) there was a noticable performance gap between List<T> and T[]. This was closed up in 3.0, so the performances are similar. I could be confusing this with .NET Reflection however :-) Using the lists is considered good practice as it is easier to use, also these are more widespread so developers are used to seeing the code. The real answer to your question I suppose is to write the code using List and judge performance from there. If the performance of your code is poor, run a profiler to see if it is the list operations ar e causing it. If so, replace your code with arrays and see what happens.

CCC solved so far: 2 (including a Hard One!) 37!?!! - Randall, Clerks