Practical .NET

Use Structs Instead of Classes to Pass Data Uniquely

The difference between Structs and Classes isn't about data vs. code: it's about what happens when you move the data around. And sometimes you want a Struct, not a Class.

Many times, when you create a class, you would have been far better off to create a Struct. The obvious example of a Struct in C# is:

public struct Person
{
     public string Name

     public int Age
}

And many developers are under the impression that's all a Struct can do: hold variables. But, in fact, Structs can hold methods and properties, as this Visual Basic example does:

Public Struct Person

     Public Name As String

     Private _Age As Integer

     Public ReadOnly Property Age As Integer

	Get

		Return _age

	End Get

     End Property

     Public Function HaveBirthday()

          Me.Age += 1

          Return Me.Age

     End Function

End Struct

The savings come in when you declare a variable using a Struct: you don't have to instantiate your variable, saving the code that uses the new keyword. You just declare the variable with the datatype. In C#:

Person pers;

pers.Name = "Peter Vogel";

In Visual Basic:

Dim pers As Person;

pers.Name = "Peter Vogel"

And that's great, but not much of a savings. The real payoff is that a Struct is a value type. That means that if you assign a struct to another variable, the other variable gets its own copy of the data. Look at this code:

Person pers2;

pers2 = pers;

pers2.Name = "Peter Vogel";

If Person was a Class, then both the pers and pers2 variables would point at the same object and updating pers2.Name would also update pers.Name. However, because they're Structs, pers2 gets its own copy of the data in pers, and updating pers2 only updates pers2. If, in your code's mainline, you pass a Struct to a method and the code in the method updates the Struct, the version of the Struct in your mainline is unaffected.

I recently took advantage of this in a multi-threading application. In my "master" method, I loaded up a Struct with control information that all the threads I was going to spin off would need. I then passed that Struct to each thread where they updated and added to the control information. Periodically, the "master" class would retrieve the Struct from each thread to see how it was doing, and update some of the information in each Struct.

If I'd used a single Class, that Class would have been shared between all threads and the master "method"; great for communication between threads, but lousy for thread isolation, which is what I needed. I could have instantiated a Class for every thread, but that would have meant loading each Class with the control information that was identical for every class. By using a Struct, I only had to do it once.

So, the next time you go to create a Class ask yourself: Do I want Class behavior or Struct behavior? And, if you think about it, you may decide that you want Struct behavior.

About the Author

Peter Vogel is a principal in PH&V Information Services, specializing in Web development with expertise in SOA, client-side development, and user interface design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His most recent book ("rtfm*") is on writing effective user manuals, and his blog on language and technical writing can be found at rtfmphvis.blogspot.com.

comments powered by Disqus

Reader Comments:

Sat, Feb 2, 2013 Tosik Buy Generic Lipitor

So, the next time you go to create a Class ask yourself: Do I want Class behavior or Struct behavior? And, if you think about it, you may decide that you want Struct behavior.

Fri, Jan 25, 2013 Jack Buy Generic Lipitor

Do I want Class behavior or Struct behavior!

Fri, Nov 23, 2012 DK

Had a query - Is it fine to use strings in structures, considering that strings are reference objects and structures are basically value types ? I assumed that structures are meant to be used when all properties are value types.

Fri, Nov 2, 2012 RP

Peter, You should probably have proof-read your VB examples. VB uses "Structure" and "End Structure", not "Struct". Also, VB lines don't end in semicolons - which in one of your examples one of them does.

Tue, Oct 2, 2012 Peter Vogel Canada

Charlie: The issue is that I don't regard that performance hit as a cost--that copying behaviour is what I want: it's the very reason that I'm using a struct rather than a class. If I take up more memory (and CPU cycles in copying) to get what I want...well, that's the cost of doing business. Better performance isn't a gain if it takes away the behaviour you want.

Mon, Oct 1, 2012 Charlie

The advantages you mention for a struct can also be a downfall if you let them get too big. The .NET Framework Guidlines Book by Abrams suggests limiting the struct size to 16 bytes. If you have several large structs in your application, you can take a performance hit because of the increased memory copying because of the pass by value. The size of a reference in passing classes is only 4 bytes (assuming a 32 bit application)

Mon, Oct 1, 2012 Peter Vogel Canada

Des: Actually, I think that the problem with constructors is much worse than you describe (at least, in Visual Basic)--I don't think you can have a "parameterless" constructor under any circumstances. Brian: I've never considered the garbage collection side of things. I would be very surprised if there's any difference if the struct is allocated on the heap which is, I believe, the default (I think that structs are only allocated on the stack if they are passed as parameters--and, even then, if the struct contains a value type that will end up on the heap). But it's worth remembering--now that I've brought it up--that the whole "stack vs. heap" thing is an implementation detail (as is garbage collection). It's not inconceivable (though very unlikely) that some future version of .NET might allocate data types differently or radically change the way garbage collection is done. It's the kind of thing that I don't worry about unless I have a gun to my head.

Fri, Sep 28, 2012 Des

While you can add methods to structs - you will face some limitations. For example if you try to add a New method with parameters, then you cannot also have a parameterless New method - the struct will not let you overload New. Also - I would not be entirely comfortable with counting on the difference in the build-in clone behavior. If it were up to me I would still prefer the class and implement iCloneable as necessary. Future revisions of the compiler and code are more clear then.

Fri, Sep 28, 2012 JE FL

This would be very helpful when creating your own entity framework instead of using classes! Thanks!!

Thu, Sep 27, 2012 Michael

Well explained and elaborated with good examples!

Thu, Sep 27, 2012

Always wondered why you would use a struct instead of an object. You gave a good example of when. Basically anytime you're going to clone your data structs are worth a close look.

Thu, Sep 27, 2012 Brian USA

Any insights on how garbage collection may differ? Is one way faster or more-efficient than the other? Thanks for the great article!

Thu, Sep 27, 2012

object.clone().

Thu, Sep 27, 2012 JP

Very cool to know, Thanks

Add Your Comments Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above

.NET Insight

Sign up for our newsletter.

I agree to this site's Privacy Policy.