structs in parameter lists

  • Thread starter Thread starter Eric Newton
  • Start date Start date
E

Eric Newton

I'm curious about the pros and cons of structs in the framework...

When say a rectangleF structure is passed through a parameter list, are all
the fields copied or is a "const" or immutable reference passed to minimize
this memory copy effect?
 
Structs are value types, and can therefore be placed on the stack.
However, what gets passed depends on how the parameter is constructed.
If the parameter is passed by value, then a copy is created on the stack. If
the parameter is passed by reference, then the struct instance lives on the
heap and the parameter is a pointer to it.
Do note that structures can hold reference types (objects) like strings as
members, but in that case, the actual contents of the reference type
instance is not part of the structure itself - the structure contains a
reference to the actual instance on the heap.

-Rob Teixeira [MVP]
 
Structs are value types, and can therefore be placed on the stack.
However, what gets passed depends on how the parameter is constructed.
If the parameter is passed by value, then a copy is created on the stack. If
the parameter is passed by reference, then the struct instance lives on the
heap and the parameter is a pointer to it.
Click to expand...

No - if the parameter is passed by reference, the value can still be on
the stack, I believe. As far as I'm aware, nothing is put on the heap
in the following program (except maybe within Console.WriteLine):

using System;

class Test
{
static void Main()
{
int i = 5;
Foo (ref i);
Console.WriteLine (i);
}

static void Foo (ref int j)
{
j = j*2;
}
}

There's no *need* for anything to be on the heap, certainly.
 
For the value type portion, that is correct. I jumped ahead of myself there.
However, embedded references to reference types within the value type would
still be pointers to heap data.

-Rob Teixeira [MVP]
 
ok cool, but my real question is when a struct is "value copied", does this
mean that say a struct is passed into N different methods, are there really
N different but equal copies or just 1?

Take the simple PointF structure, with an X and Y... not much cost but say
theres a structure with 20 fields, all value types, and passed by value...
do all the values get copied to another struct instance? and doesnt that
seem horribly inefficient to the N degree? (Saying that because the
runtime has to copy N fields to a new "struct" instance on the local stack)

If that's the case, then wouldn't passing structs around be (in theory)
worse then defining the "colleciton of like-fields" as a class and get a
reference allocated on the heap?

These are some things, that in my mind havent really been addressed by the
runtime gurus... and I'm just curious, efficiency-wise which is better...


--
Eric Newton
C#/ASP Application Developer
http://ensoft-software.com/
(e-mail address removed)-software.com [remove the first "CC."]
 
Eric Newton said:
ok cool, but my real question is when a struct is "value copied", does this
mean that say a struct is passed into N different methods, are there really
N different but equal copies or just 1?
Click to expand...

N different but equal copies.
Take the simple PointF structure, with an X and Y... not much cost but say
theres a structure with 20 fields, all value types, and passed by value...
do all the values get copied to another struct instance? and doesnt that
seem horribly inefficient to the N degree?
Click to expand...

Well, I don't know about "horribly inefficient" but it's certainly not
ideal. Then again, most of the time you wouldn't have 20 fields in a
value type.
(Saying that because the
runtime has to copy N fields to a new "struct" instance on the local stack)

If that's the case, then wouldn't passing structs around be (in theory)
worse then defining the "colleciton of like-fields" as a class and get a
reference allocated on the heap?
Click to expand...

If you're happy with reference type semantics, then references are
indeed very efficient. Sometimes value type semantics are preferrable
though - mind you, I find that quite rare.
 
Back
Top