< Continued from page 1

When Peter reviewed a draft of this article, he noted that, "It doesn't hit one point that I have problems with. I really don't understand "classes". How do I do it with structures?"

The same way, Peter!

You can think of a Structure as being like a stripped down Class. Classes and Structures are both container types. That means they hold other types as members. In this case, theTime and theColor are held as members.


But a Structure is a "value type". (Information is stored directly on the "stack".) A Class is a "reference type". (Information is stored on the run-time "heap".) Programmers with experience in other languages sometimes think of a "structure" as being just a way of defining a hierarchical memory store. (Like a "Data Definition" section in Cobol.) But Classes and Structures are really more like two alternative ways of managing memory. VB6 programmers will recognize the Structure as being similar to the old UDT (User Data Type). From the point of view of the programmer, Classes and Structures are usually more the same than they are different.

For example, the code above will run exactly the same way if the two statements ...

Public Class myIDC
... ' the rest of the statements are the same
End Class

... are replaced with equivalent Structure statements ...

Public Structure myIDC
... ' the rest of the statements are the same
End Structure

There are differences, of course. Microsoft has some surprisingly good pages that explain it all at MSDN.

This article isn't about "Structures versus Classes" however, so I'll just repeat the best of the MSDN documentation - this general advice.

----------------------

When you are defining a container type, consider the following criteria.

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
• If your container type does not fit clearly into either of these categories, define a Class. Classes are more flexible than structures, and the storage and performance differences are often negligible. Structures are intended primarily for types that behave like built-in types, not necessarily for general-purpose use.

----------------------

Another thing the Microsoft documentation fails to tell you is that, now that we have done all this, it has just about nothing to do with the old VB6 ItemData property. It's all about objects. And that's really the way it should be because you just don't need ItemData. You need objects.