(un)boxing

  • Thread starter Thread starter Alistair Welchman
  • Start date Start date
A

Alistair Welchman

I have a Hashtable of ints keyed on Guids, and I want to do the following:

foreach ( DataRow row in dsWorkDays.Tables[0].Rows )

{

Guid PersonId = (Guid)row["PersonID"];

DateTime Day = (DateTime)row["Datum"];

rLastWorkDays.Increment( PersonId, Day.DayOfWeek,
++((int)Offsets[PersonId]) );

}

that is, increment the offset for the current Guid and call a function with
the new value.

This fails at compile time with the message

The left-hand side of an assignment must be a variable, property or
indexer

I assume that the rule is that when you access a hashed value type, you
don't get a reference but a copy. When you assign the copy, everything is
OK, but when, like here, you just try and perform an operation on it, the
compiler recognises that the operation will always be useless because it's
performed on a temporary and refuses to comply.

If this is right, my question is: why isn't boxing automatically invoked? I
can do it myself of course, but then I have to write about the same amount
of code as I would just to store the value, increment it, call the function,
and tuck the incremented value back in the Hashtable. Any clarifications?
Perhaps I've misunderstood the rule.

Alistair Welchman
 
I don't see how (un)boxing would help you anyway. The point is the Hashtable
is returning you a copy of the value when you call 'Offsets[PersonId]) ' and
consequently you have to place it back into the Hashtable for the value to
be updated:

Offsets[PersonId] = ++((int)Offsets[PersonId]);

Regards
Lee
 
You only get a copy back from a Hashtable when you've stored a value type,
otherwise you get a reference.

But you're right that boxing won't help, because of the way operator
overloading is done in C#; that is always with static functions. This is
unlike C++ where you have the choice between member and non-member
functions. My thought was: if operator++ could be overloaded using a member
function, I would expect it to behave like the member function SomeRefType
Inc() in this snippet:

DoComputation( ((SomeRefType)myHash[myKey]).Inc() );

And then a suitably defined boxed version of a value type would handle my
situation.

Anyway, your code suggestion doesn't compile either:

Offsets[PersonId] = ++((int)Offsets[PersonId]); // same error as before

I'm now more confused than I was at first, since this can't have to do with
the creation of a temporary that's never assigned storage.

What I'm doing is this:

int Offset = (int)Offsets[PersonId];
rLastWorkDays.Increment( PersonId, Day.DayOfWeek, ++Offset );
Offsets[PersonId] = Offset;

which, while hardly the end of the world, is not as clear and conscise as it
could have been.

Any *more* clarifications?

Alistair

Lee Alexander said:
I don't see how (un)boxing would help you anyway. The point is the Hashtable
is returning you a copy of the value when you call 'Offsets[PersonId]) ' and
consequently you have to place it back into the Hashtable for the value to
be updated:

Offsets[PersonId] = ++((int)Offsets[PersonId]);

Regards
Lee


Alistair Welchman said:
I have a Hashtable of ints keyed on Guids, and I want to do the following:

foreach ( DataRow row in dsWorkDays.Tables[0].Rows )

{

Guid PersonId = (Guid)row["PersonID"];

DateTime Day = (DateTime)row["Datum"];

rLastWorkDays.Increment( PersonId, Day.DayOfWeek,
++((int)Offsets[PersonId]) );

}

that is, increment the offset for the current Guid and call a function with
the new value.

This fails at compile time with the message

The left-hand side of an assignment must be a variable, property or
indexer

I assume that the rule is that when you access a hashed value type, you
don't get a reference but a copy. When you assign the copy, everything is
OK, but when, like here, you just try and perform an operation on it, the
compiler recognises that the operation will always be useless because it's
performed on a temporary and refuses to comply.

If this is right, my question is: why isn't boxing automatically
Click to expand...
invoked?
I
can do it myself of course, but then I have to write about the same amount
of code as I would just to store the value, increment it, call the function,
and tuck the incremented value back in the Hashtable. Any clarifications?
Perhaps I've misunderstood the rule.

Alistair Welchman
Click to expand...
Click to expand...
 
Anyway, your code suggestion doesn't compile either:
Offsets[PersonId] = ++((int)Offsets[PersonId]); // same error as before

I'm now more confused than I was at first, since this can't have to do with
the creation of a temporary that's never assigned storage.
Click to expand...

It has to do with the '++' operator. This operator actually changes the
memory location in question. Since the location returned by
Offsets[PersonId] is a temporary location, using the increment operator on
it is useless. The fact that '++' returns the new value is a side-effect. So
while your code seems right, it would be much clearer to use

Offsets[id] += 1

or, if that doesn't work,

Offsets[id] = (int)Offsets[id] + 1

The latter will compile fine, and the former should. Hmm. Maybe I'm not
really understanding what you're asking?

Chris
 
Alistair Welchman said:
Anyway, your code suggestion doesn't compile either:

Offsets[PersonId] = ++((int)Offsets[PersonId]); // same error as before

I'm now more confused than I was at first, since this can't have to do with
the creation of a temporary that's never assigned storage.

What I'm doing is this:

int Offset = (int)Offsets[PersonId];
rLastWorkDays.Increment( PersonId, Day.DayOfWeek, ++Offset );
Offsets[PersonId] = Offset;

which, while hardly the end of the world, is not as clear and conscise as it
could have been.

Any *more* clarifications?
Click to expand...

Try:

Offsets[PersonId] = ((int)Offsets[PersonId])+1;

Note that in IL itself, you can modify the value within the box - you
just can't do it in C# because unboxing in C# always causes a copy to
be made.
 
Back
Top