I want to know if it is possible to pass a Structure as a parameter in c# method and if possible, is it a good practice to do so?

I have a c# method which is taking six arguments, i really hate that. I could create a carrier class for that and pass it as an argument, but i want to know if structure could do the job.

I want to mention here that few arguments to that method are of ref type and few are of value type.

2 Answers 2


Yes, you can do it, but you need to bear a couple of things in mind.

First is that a value type (struct) is stored on the stack (often, not always, see comment-thread), rather than the heap. The stack is limited in size and large objects shouldn't be stored on it. That said, there is a minor performance benefit to storing variables on the stack.

The next is that a value type passed as a method argument will be copied, rather than referenced. This can be a good thing. At least you know that your variable isn't going to be changed by the method. However, the copy is stored on the stack, so be careful. Also, sometimes you want a method to be able to edit the contents of your object.

Finally, you need to know that reference objects within a struct are just pointers to objects on the heap. So if you edit the contents of one of those classes (unless, like a string, they are coded to be immutable), you are going to affect the contents of your own object, even though it is supposedly immutable. This can be very confusing.

As soon as you said that some of the contents are reference objects, I thought "I'd just stick to a class."

As a general rule:

  • Only use structs to hold other immutable objects.
  • Only use structs for small collections of data.
  • Only use structs where changing one item within it will probably change all of the others.

Take an address as a good example:

  • All contents are strings and thus immutable.
  • It's only a half-dozen pointers.
  • While you might remain in the same zipcode, for example, if you move house then you probably change your entire address.
  • 1
    @jk: You mean that it could be boxed? Do you not think the answer is complicated enough? And, arguably, if it's boxed then it's no longer a value object, it's boxed inside a reference.
    – pdr
    Commented Dec 6, 2012 at 12:01
  • 2
    – jk.
    Commented Dec 6, 2012 at 12:06
  • 2
    No, the point is not that we should be uber-correct and enumerate how a structure object could be stored in which conditions (by the way, you neglect the option to use registers). The point is that it does not matter and thus shouldn't be mentioned at all. The important differences are the value semantics (what you call copying). Especially in this context -- a couple of method arguments should always be small enough for stack space taken to be no concern.
    – user7043
    Commented Dec 6, 2012 at 12:12
  • 1
    @delnan: I disagree quite strongly. I think if you're going to start messing around with structs, you need to know the effect of making one too large. Even a half dozen pointers makes quite a big object, if it's going to be copied repeatedly, and what about the next reader who wants to apply the same logic to a 20- or 50-parameter method?
    – pdr
    Commented Dec 6, 2012 at 12:20
  • 1
    Half a dozen pointers are 6 * 4 = 24 bytes (on 32 bit systems; but merely twice as much on 64 bit). You'd need 40 copies of those to even fill a KiB, where stacks are commonly one to a few MiB large. As for 20- or 50-parameter methods: If you have so many parameters, or object attributes, you have more urgent problems than a waste of stack space. That, coupled with the hope that so many members/parameters are exceptional, makes me think it's not worth adding this (otherwise irrelevant) information to every discussion of structs.
    – user7043
    Commented Dec 6, 2012 at 12:31

Yes you can (and should) have structures and classes as arguments to methods. This will help encapsulate your data and make it easier if you need to pass more data to your methods. You simply extend the class and recompile.

Obviously, just extending a class is to be avoided if it's a public interface, but if it's just internal to your application then there shouldn't be a problem.

  • And Structure could do the same job as well even for reference type variables? Which approach is better if we could use both of them?
    – MegaMind
    Commented Dec 6, 2012 at 11:46
  • @MegaMind I'd use a class for preference, but you could use a structure quite happily.
    – ChrisF
    Commented Dec 6, 2012 at 11:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.