(un)boxing

[Alistair Welchman]

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

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

{

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

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

rLastWorkDays.I ncrement( 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

[Lee Alexander]

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" <th*******@eart hlink.net> wrote in message
news:OL******** *****@tk2msftng p13.phx.gbl...

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

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

{

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

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

rLastWorkDays.I ncrement( 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

[Alistair Welchman]

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)m yHash[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.I ncrement( 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" <lee@No_Spam_Pl ease_Digita.com > wrote in message
news:e9******** ******@tk2msftn gp13.phx.gbl...

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" <th*******@eart hlink.net> wrote in message
news:OL******** *****@tk2msftng p13.phx.gbl...

I have a Hashtable of ints keyed on Guids, and I want to do the following:
foreach ( DataRow row in dsWorkDays.Tabl es[0].Rows )

{

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

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

rLastWorkDays.I ncrement( 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

[Chris Capel]

> 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.

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

[Jon Skeet]

Alistair Welchman <th*******@eart hlink.net> wrote:

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.I ncrement( 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?

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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too