Weird Valuetype behavior

[Sahil Malik [MVP]]

Okay so lets say I have a valuetype - lets say DateTime.

Look at this code .

List<DateTime> dt = new List<DateTime>( ) ;
dt.Add(new dateTime(1999,1 2,1))
dt[0].AddDays(1) ;
<--- This statement won't actually change the date time stored in the
List<T> dt.

The best I can determine is that soon as a method is called on any date time
stored in "dt", it creates a new instance of DateTime, and leaves the
original inside dt untouched. Similar behavior for non generic collections.

Can anyone explain the reasoning?

- Sahil Malik [MVP]
http://codebetter.com/blogs/sahil.malik/

[Bill Butler]

"Sahil Malik [MVP]" <co************ *****@nospam.co m> wrote in message
news:%2******** ********@TK2MSF TNGP12.phx.gbl. ..

Okay so lets say I have a valuetype - lets say DateTime.

Look at this code .

List<DateTime> dt = new List<DateTime>( ) ;
dt.Add(new dateTime(1999,1 2,1))
dt[0].AddDays(1) ;
<--- This statement won't actually change the date time stored in the
List<T> dt.

The best I can determine is that soon as a method is called on any date
time
stored in "dt", it creates a new instance of DateTime, and leaves the
original inside dt untouched. Similar behavior for non generic
collections.

Can anyone explain the reasoning?

This has nothing to do with the collections
AddDays() (and similar methods)
do not modify the original DateTime

you need to capture the return value
DateTime now = DateTime.Now;
DateTime datetime = now.AddDays(1);

Bill

[Bruce Wood]

As Bill Butler pointed out, AddDays doesn't modify the original
DateTime structure.

However, even if it did, I don't believe that it would change the
DateTime stored in the List<DateTime>. Here is why.

Remember two things: first, a reference like dt[0], where dt is a
List<DateTime>, is really just a method call. Somewhere in the
definition for List<T> is a method declaration that unwinds to look
something like this:

public DateTime this[index i]
{
DateTime dt = ... ;
return dt;
}

Second, remember that value types, like DateTime, are always copied.

So, what will happen is that some code will run that will find the
correct DateTime value within the list. That value will then be _copied
on the stack_ as the return value from the this[] indexer method. Any
method or property that then modifies that DateTime will modify the
temporary value on the stack, the value that was returned from the
indexer.

Therefore, saying

List<MyValueTyp e> aList = ... ;
aList[i].MethodThatModi fiesValue();

will modify a temporary copy of the value, not the value in the
List<MyValueTyp e>. The value in the List<MyValueTyp e> will remain
unchanged.

This doesn't even have to do with boxing and unboxing... it has to do
with how value types are returned from method calls.

All of which demonstrates once again why creating mutable value types
is just asking for trouble.... :-)

[Sahil Malik [MVP]]

Thanks Bruce.

Instead of

public DateTime this[index i]
{
DateTime dt = ... ;
return dt;
}
Why didn't theyhave something like this -
public DateTime this[index i]
{
return innercollection[i];
}
Would that help the situation any?

- Sahil Malik [MVP]
http://codebetter.com/blogs/sahil.malik/


"Bruce Wood" <br*******@cana da.com> wrote in message
news:11******** **************@ l41g2000cwc.goo glegroups.com.. . As Bill Butler pointed out, AddDays doesn't modify the original
DateTime structure.

However, even if it did, I don't believe that it would change the
DateTime stored in the List<DateTime>. Here is why.

Remember two things: first, a reference like dt[0], where dt is a
List<DateTime>, is really just a method call. Somewhere in the
definition for List<T> is a method declaration that unwinds to look
something like this:

public DateTime this[index i]
{
DateTime dt = ... ;
return dt;
}

Second, remember that value types, like DateTime, are always copied.

So, what will happen is that some code will run that will find the
correct DateTime value within the list. That value will then be _copied
on the stack_ as the return value from the this[] indexer method. Any
method or property that then modifies that DateTime will modify the
temporary value on the stack, the value that was returned from the
indexer.

Therefore, saying

List<MyValueTyp e> aList = ... ;
aList[i].MethodThatModi fiesValue();

will modify a temporary copy of the value, not the value in the
List<MyValueTyp e>. The value in the List<MyValueTyp e> will remain
unchanged.

This doesn't even have to do with boxing and unboxing... it has to do
with how value types are returned from method calls.

All of which demonstrates once again why creating mutable value types
is just asking for trouble.... :-)

[Bruce Wood]

Nope. No joy. It's still a method with a return value, which still
means that the value type (in this case DateTime) gets copied onto the
stack, which still means that what you get back is a copy, not a
reference to the item in the array.

You have to think of arrays of complex value types like DateTime in the
same way that you think of arrays of integers. You can put a new
integer at a particular place in the array, but you can't "modify" the
integer that's already in the array... that doesn't make any sense.

Which, again, is why mutable value types are so weird. Yes, C# lets you
create them, but I consider that very, very fragile code, and would ask
the person why they're doing it.

No, no matter how you slice it, you have to say:

List<DateTime> dt = new List<DateTime>( ) ;
dt.Add(new dateTime(1999,1 2,1))
dt[0] = dt[0].AddDays(1) ;

in other words, on that last line you have to read the value from
dt[0], call AddDays to produce a new value from it, and replace the
contents of dt[0] with that new value, just the way you would with an
integer:

intList[0] = intList[0] + 1;

(By the way, I haven't tried it, but if I'm right, the following code
should have the same effect that you described for DateTimes:

intList[0]++;

The value of the integer at intList[0] should not change because the
postincrement operator is incrementing a copy on the stack, not the int
stored in the List.)