VB.NET: is using Strutures considered nasty?

Question

I use to use Structures quite a lot in the VB6 days, and try to avoid them now with .NET. Just wondering if using structures in 2010 instead of a Class is considered nasty?

Thanks for the help.

Answer 1

Choosing a Structure takes consideration instead of being inherently "nasty". There are reasons why a Structure can be nasty; however there are also reasons a Class can be nasty in its own way...

Basically when you decide between these two object oriented kinds of containers, you're deciding how memory will be used.

---

There are different semantics associated with Structure and Class in VB.NET and they represent different memory usage patterns.

By creating a Class you're creating a reference type.

• good for large data
• memory contains a reference to the object location on the heap (like the concept of pointing to an object) though happens transparently to the VB.NET programmer because you're in "managed mode".

By creating a Structure you're creating a value type.

• good for small data
• memory allocated contains the actual value
• be judicious because these are apt to get pushed on the stack area of memory - too large and you could run into issues.

Also some good video resources on YouTube if you're an audio learner.

Many articles on the Internet like these MSDN articles to teach the basics and details:

• Value Types and Reference Types
• 7.1 Types - Reference and Value
• MSDN Type Fundamentals - subheading: Reference and Value Types

Example

Answer 2

It's considered pretty bad to use anything without understanding the implications.

Structures are value types, not reference types - and as such, they behave slightly differently. When you pass a value type, modifications are on a copy, not on the original. When you assign a value type to an object reference (say, in a non-generic list), boxing occurs. Make sure you read up on the full effect of choosing one over the other.

Answer 3

Structures exist because in some scenarios they make more sense than classes. They are particular useful for representing small abstract data types such as 3D points, latitude-longitude, rational numbers, etc.

The basic motivation for using structs is to avoid GC pressure. Since structs live inline (on the stack or inside whatever container you put them in) rather than on the heap, they typically result in far fewer small allocations, which makes a huge difference if you need to hold an array of one million points or rationals.

A key issue to watch out for is that structs are value types, and thus are generally passed around by value (the obvious exception being ref and out parameters). This has important implications. For instance:

Point3D[] points = ...;
points[9].Move(0, 0, 5);

The above code works fine, and increases the z coordinate of the 10th point by 5. The following code, however:

List<Point3D> points = ...;
points[9].Move(0, 0, 5);

Will still compile and run, but you will find that the z coordinate of the 10th point remains unchanged. This is because the List's index operator returns a copy of the point, and it is the copy that you are calling Move on.

The solution is quite simple. Always make structs immutable by marking all fields readonly. If you still need to Move points around, define + on the Point3D type and use assignment:

points[9] = points[9] + new Point3D(0, 0, 5);

Answer 4

Read this for some understanding benefits of structures vs classes and vice-versa.

A structure can be preferable when:

• You have a small amount of data and simply want the equivalent of the UDT (user-defined type) of previous versions of Visual Basic
• You perform a large number of operations on each instance and would incur performance degradation with heap management
• You have no need to inherit the structure or to specialize functionality among its instances
• You do not box and unbox the structure
• You are passing blittable data across a managed/unmanaged boundary

A class is preferable when:

• You need to use inheritance and polymorphism
• You need to initialize one or more members at creation time
• You need to supply an unparameterized constructor
• You need unlimited event handling support

Answer 5

To answer your question directly, there is nothing inherantly wrong with using a structure in VB.NET. As with any design decision you do need to consider the consequences of this decision.

It's important that you're aware of the difference between a class and a structure so that you can make an educated decision about which is appropriate. As stated by Alex et al, one of the key differences between a structure and a class is that a structure is considered a value type and a class is considered a reference type.

Reference types use copy-by-reference sematics, this means that when an object is created or copied, only a pointer to the actual object is allocated on the stack, the actual object data is allocated on the heap.

In contrast, value types have copy-by-value sematics which means that each time a value type (e.g. a structure) is copied, then the entire object is copied to a new location on the stack/

For objects with a small amount of data, this isn't really a problem, but if you have a large amount of data then using a reference type will likely be less expensive in terms of stack allocations because only a pointer will be copied to the stack.

Microsoft have guidelines on the use of structures that more precisely describe the differences between classes and structures and the consequences of choosing one over the other