Structures vs Classes

Kane Jeeves

Active member
Joined
May 17, 2006
Messages
44
Programming Experience
5-10
I know about and have used plenty of structures and classes. I've also read about value types vs reference types, stack vs. heap. Aside from the various differences in features, are there performance benefits to using one versus the other? I have a few large objects, say 50+ fields/properties (some of which will themselves be objects), with several methods, etc. Structures seem the way to go (don't need inheritance) because they're easier to work with. But I don't really understand why. Is using stack-based better or worse performance-wise maybe?

Thanks!

Kane
 
Thanks

Thanks for the links. I guess I should look at documentation first instead of blindly googling. :)

Structures are easier in the sense that you don't have to setup both private variables and corresponding property get/sets for each one.

- Kane
 
Structures are easier in the sense that you don't have to setup both private variables and corresponding property get/sets for each one.

- Kane
That is not a difference, it is possible to do the same in classes, but fields should always be private according to guidelines (except some shared/constants). Writing a property is also no more work than writing a field, just write "property" and press Tab key and fill in name and type.
 
One more thing about structures. Performance, when you access its members is better because it doesn't have to resolve the address a reference variable points to, because the variable is the value itself. However, whenever you assign a variable to the structure's value, you copy its whole content from one variable to another while an object just copies its reference (32 bits).

All else is but consequences of the fact that your variable is the data (structures) or points to it (classes). Along with some debatable design decisions...

Performance is hardly ever important, so most of the time, these are the two points I take in consideration when I choose between them.

An assignation for structures is a shallow copy of it, so if you intend to share it among more than one variable at a time, choose classes.

Do you intend to use methods or properties (I mean those get/set constructs) from outside the structure itself before you know all of the structure's data? Then this is not possible with structures either, you must use classes. That is because you cannot call a method from a structure which has some uninitialized fields. That is obvious because the member data of a structure is NOT initialized automatically. You don't have to use the new keyword to create a structure...

All this leads to the conclusion that structures are useful only if you have related data that do not affect each other. And even then, it may be better not to take any chance or you will end up excepting a behavior like that of reference variables and wondering why the value of that structure's member is wrong.

You may consider it in cases like an application settings structure wrapped inside a static class to access its values or similar very narrow targeted applications. But overall, you don't need to know about structures until you have to work with someone else who does...

BTW. In the first of JohnH's link, you will find that there is a list of situations where not to use structures. There is nothing about when to use them because there is no point in doing so!
 
One more thing about structures. Performance, when you access its members is better because it doesn't have to resolve the address a reference variable points to, because the variable is the value itself.
Both value and reference variables do point to memory locations where the data is stored, the difference is where the data is stored and how these types behave. There are performance benefits for both class and structure considering usage.

That is obvious because the member data of a structure is NOT initialized automatically.
Perhaps not what you had in mind, but data members are initialized, from the article:
Every structure has an implicit public constructor without parameters. This constructor initializes all the structure's data elements to their default values.

there is a list of situations where not to use structures. There is nothing about when to use them because there is no point in doing so!
Considering that all VB data types except Object and String are defined by structures I'd say there is. Look through the System namespace and you'll find many examples, structures are also used in many other cases in .Net Framework class library. The article lists where Structure type should be considered when it is "small, short-lived and embedded" and has "all of the following characteristics".
 
Perhaps not what you had in mind, but data members are initialized, from the article:

I must admit I didn't know the default constructor did that, but that's still of very little use...

VB.NET:
public structure Point
    public X as integer;
    public Y as integer;

    public sub SetDefaultX()
        X = 13 ' let's say it read from the system settings or something
    end sub



    public sub SetDefaultY()
        Y = 19 ' let's say it read from the system settings or something    
    end sub

    public sub new(readDefault as boolean)
        if (readDefault) then
            SetDefaultX() ' Compilation error
            SetDefaultY() ' Compilation error  
        else
            this.new() ' the default zeros for every member
        end if
    end sub
end structure

That is because you cannot use methods until the structure's members are fully initialized! I'm not sure about VB.NET, but here's the same error outside a constructor in C# :

VB.NET:
Point pt; // That from the previous code tag, not from system.drawing
pt.SetDefaultX(); // compilation error
pt.SetDefaultY(); // compilation error

To resolve this, you had to use the new keyword to initialize the structure's memory location first (I think the process of initializing simply clears the whole memory area to zeros, but it may me more complex), then start the code sould work. But this works :

VB.NET:
Point pt; // That from the previous code tag, not from system.drawing
pt.X = 0;
pt.Y = 0;
SetDefaultX(); // works fine
SetDefaultY(); // works fine

I read about all those a while back and there are still some stuff I had to try because I simply forgot about them. The only good reason not to use it is not about limitations, but more about how most people smply don't know about them enough. It's better to stick with well known tools so someone else can repair the product.

Both value and reference variables do point to memory locations where the data is stored, the difference is where the data is stored and how these types behave. There are performance benefits for both class and structure considering usage.

I get that a reference variable points to a 32 bits memory address which points where the object's members are grouped (the address is "on the stack" and the object is "on the heap"). A value variable points to the memory address where the object's members are directly (the object is "on the stack"). An assignation copies either the 32 bits for a reference variable or all of the object's members if it is a value. (I say 32 bits but that's 64 bits on x64 systems)
 
Last edited:
I must admit I didn't know the default constructor did that, but that's still of very little use...
On the contrary, else you would have to create instances of the X/Y Integer fields with New keyword before you used them as with classes. Instead they are initialized when declared:
article said:
Therefore, Dim s As struct1 is equivalent to Dim s As struct1 = New struct1().
The only good reason not to use it is not about limitations, but more about how most people smply don't know about them enough. It's better to stick with well known tools so someone else can repair the product.
Not knowing something well enough is only an incentive to learn it better, not a reason to avoid it.
That is because you cannot use methods until the structure's members are fully initialized!
There is no compilation error using a member field value in constructor of a Structure. There is also no compilation error using an instance method from the constructor setting/getting these fields, because the value type member fields are already initialized when the constructor method runs. There is no difference between constructors with or without parameters here.

I really have no clue why you start posting C# codes here, this is a VB.Net forum. What you can or can't do with C# is 100% irrelevant for us.
 
I really have no clue why you start posting C# codes here, this is a VB.Net forum. What you can or can't do with C# is 100% irrelevant for us.

You are right, I expected the behavior to be the same since they both work on the same framework, I didn't think this could have been implemented differently... My mistake. However, 100% irrelevant seems quite extreme. Don't you use C# code samples now and then as examples?

Not knowing something well enough is only an incentive to learn it better, not a reason to avoid it.

If you don't know something well enough, you should learn about it. But if your coworkers don't know about it (or don't know about it deeply enough), throwing new contructs at them won't do you much good...

And you cannot tell if a variable declaration create a class or a structure on first sight! It is merely a matter of preference in the end, but I do prefer to avoid something that will have people ask "why does .. structuresList(index).someProperty = someValue .. not change anything in the list?"...
 
Back
Top