Re: Do I need to create a struct? - C# Discussion Boards

14-Dec-09 5:05

Hello,

I'd like to create an array, and have it contain two items (two-dimensional) of two different types.

I believe the best way to do this is create my own type, however, I'm unsure how to handle the need for an array.

For instance, I want to create something that will take in:

SnapShot[i] = ( DateTime DateTime.Now, Int Size );

How can this be done?

Thanks,

Matt

OriginalGriff14-Dec-09 5:16

OriginalGriff

14-Dec-09 5:16

Why not use a Dictionary?[^]

All those who believe in psycho kinesis, raise my hand.

bbranded14-Dec-09 5:17

14-Dec-09 5:17

Thanks!

This will work for two items.

What can I do if I want to store more items?

Thanks,

Matt

OriginalGriff14-Dec-09 5:21

OriginalGriff

14-Dec-09 5:21

Then I would create a class to hold the info, and either use a Dictionary or hold it in a List<T>. You get the flexibility of the array, but without the need to specify the initial size .

All those who believe in psycho kinesis, raise my hand.

Keith Barrow14-Dec-09 5:18

14-Dec-09 5:18

I'd suggest creating a SnapShotInformation class with Date and Size properties.
You can then maintain a List<SnapShotInformation>. This has the advantage of being more maintainable and the size of the list is dynamic (ie you can add more items to is and it will resize).

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

Saksida Bojan14-Dec-09 5:58

Saksida Bojan

14-Dec-09 5:58

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 h14-Dec-09 6:07

N a v a n e e t h

14-Dec-09 6:07

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 Bojan14-Dec-09 6:14

Saksida Bojan

14-Dec-09 6:14

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?

Keith Barrow14-Dec-09 6:40

14-Dec-09 6:40

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

bbranded14-Dec-09 7:27

14-Dec-09 7:27

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

Keith Barrow14-Dec-09 8:03

14-Dec-09 8:03

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

bbranded14-Dec-09 8:07

14-Dec-09 8:07

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 Barrow14-Dec-09 8:18

14-Dec-09 8:18

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

bbranded14-Dec-09 8:37

14-Dec-09 8:37

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 Barrow15-Dec-09 1:16

15-Dec-09 1:16

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 Smile | :)

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