is value type really cheap?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

In some cases value type is expensive than class. For example:
class myclass(DataTime dateTime);

DataTime is a structure therefore a value type. If it is a reference type I
can do:

myclass aa = new myclass(null);

no memory located for DataTime instance. But because it is a value type, I
have to do

DataTime dd = new DataTime();
myclass aa = new myclass(dd);

now double DateTime instances are allocated and but I need none in this case.

My conclusion:
Because value type not really save memory. cancel it will be better.
 
Fei Li said:
In some cases value type is expensive than class. For example:
class myclass(DataTime dateTime);

DataTime is a structure therefore a value type. If it is a reference type I
can do:

myclass aa = new myclass(null);

no memory located for DataTime instance.
Click to expand...

There's still the memory allocated for the reference though - that will
be 4 bytes on today's systems.
But because it is a value type, I
have to do

DataTime dd = new DataTime();
myclass aa = new myclass(dd);

now double DateTime instances are allocated and but I need none in this case.
Click to expand...

Not sure what you mean by "double DateTime instances are allocated".
There is a value on the stack, which isn't going to take any memory
after that stack frame has been torn down. There's a value on the heap
as part of the new myclass instance, and that will take up 8 bytes. So
yes, you get a 4 byte saving in this case - but only if you don't need
to use the DateTime.

Now suppose DateTime were a reference type and you *did* need it. You'd
need to create a separate instance of DateTime on the heap, which would
take at least 16 bytes, *plus* you'd still have the reference to it - a
total of 20 bytes, 12 bytes more than the case where it's a value type.
My conclusion:
Because value type not really save memory. cancel it will be better.
Click to expand...

Any conclusion based on a single use case is unlikely to be
particularly general, IMO.

I don't tend to create new value types myself, but I'm generally
grateful for the ones which are available.
 
Patty O'Dors said:
Consider also the difference between memory allocation on the stack and the
heap.
Click to expand...

.... but bear in mind that the idea that value types are always
allocated on the stack is incorrect. (A value type variable which is
part of a reference type is allocated along with the rest of the
instance - on the heap.)
 
oh, obviously. Only a value type that's *only* a value type and has got
procedure scope is on the stack, right?
 
Hi Fei,

I saw the other guys gave you an good explanation of the differences between
value and reference types and why we need both.
I'd only like to add that if you need constructor (or method) that doesn't
accept DateTime parameter istead you can provide an overload

I believe is better to create the object as
myclass aa = new myclass();
if you don't want to provide that DateTime parameter

isntead of having
myclass aa = new myclass(null);

The question is how you going to find out latter what kind of constructor is
used to create the object. Well in this case you should be creative.

BTW C# 2 is going to help with this one by introducing the 'nullable value
types'
 
Back
Top