Is this a bug?

[John Brown]

Can someone confirm whether the following technique is now broken in .NET
2.0 (it worked in 1.1).

// Avoid boxing and losing our return value
object inoutCancel = false;

Control.Invoke(..., new object[] { ..., inoutCancel});
bool cancel = (bool)inoutCancel;

"inoutCancel" is always returned as "false". Any feedback would be
appreciated. Thanks.

 

[John Brown]

Can someone confirm whether the following technique is now broken in .NET

2.0 (it worked in 1.1).

// Avoid boxing and losing our return value
object inoutCancel = false;

Control.Invoke(..., new object[] { ..., inoutCancel});
bool cancel = (bool)inoutCancel;

"inoutCancel" is always returned as "false". Any feedback would be
appreciated. Thanks.

Sorry, if I didn't make it clear, "inoutCancel" is an "out" parameter.

 

[Jon Skeet [C# MVP]]

Can someone confirm whether the following technique is now broken in .NET
2.0 (it worked in 1.1).

// Avoid boxing and losing our return value
object inoutCancel = false;

That's not avoiding boxing at all - it's just boxing it earlier!

Control.Invoke(..., new object[] { ..., inoutCancel});
bool cancel = (bool)inoutCancel;

"inoutCancel" is always returned as "false". Any feedback would be
appreciated. Thanks.

In 1.1, when an out/ref parameter which was originally a boxed value
type changes, the value in the box changes. In 2.0, the element in the
array is set to a new boxed value. Here's a small app to demonstrate
this:

using System;
using System.Reflection;

class Test
{
public static void SetToFive (out int x)
{
x = 5;
}

static void Main()
{
MethodInfo mi = typeof(Test).GetMethod("SetToFive");

object parameter = 0;
object[] parameters = new object[]{parameter};
mi.Invoke (null, parameters);

Console.WriteLine ("After invocation:");
Console.WriteLine ("parameter={0}", parameter);
Console.WriteLine ("parameters[0]={0}", parameters[0]);
}
}

On .NET 1.1, the output is:
After invocation:
parameter=5
parameters[0]=5

On .NET 2.0, the output is:
After invocation:
parameter=0
parameters[0]=5

 

[John Brown]

That's not avoiding boxing at all - it's just boxing it earlier!

Thanks the feedback. In actuality however, that was a quote from Chris Sells
who's probably more widely known in C++ circles (which is my own
background). You can read what he said here if you're interested (just
search for "avoid boxing" and see the paragraph that immediately follows

http://msdn.microsoft.com/library/en-us/dnforms/html/winforms08162002.asp?frame=true

In 1.1, when an out/ref parameter which was originally a boxed value
type changes, the value in the box changes. In 2.0, the element in the
array is set to a new boxed value. Here's a small app to demonstrate
this:

using System;
using System.Reflection;

class Test
{
public static void SetToFive (out int x)
{
x = 5;
}

static void Main()
{
MethodInfo mi = typeof(Test).GetMethod("SetToFive");

object parameter = 0;
object[] parameters = new object[]{parameter};
mi.Invoke (null, parameters);

Console.WriteLine ("After invocation:");
Console.WriteLine ("parameter={0}", parameter);
Console.WriteLine ("parameters[0]={0}", parameters[0]);
}
}

On .NET 1.1, the output is:
After invocation:
parameter=5
parameters[0]=5

On .NET 2.0, the output is:
After invocation:
parameter=0
parameters[0]=5

This change breaks existing code however. Maybe the original behaviour was a
problem and had to be corrected for some reason but at first glance this
change seems totally absurd and counterintuitive. The array contains a
reference to an object which is being passed as an "out" parameter. That
object should therefore be changed and it's potentially dangerous to do
anything else (or potentially error prone anyway since the programmer may be
storing the original reference somewhere which will no longer point to the
updated value - any such references must therefore be updated after each
call) . More importantly perhaps, how do they justify replacing the original
array element with another. It's syntactically inconvenient as well since
you can no longer create the array on the fly (in the function call) because
you now have to keep it around in order to index into it afterwards. Even
worse, you have to hardcode the index of the parameter itself or otherwise
store it somewhere so you can index into the array afterwards (not only
ugly, but the index will have to be changed if the parameter's ordinal
position ever changes). This is all brutal IMO and I'd like to know what the
justification was (assuming it wasn't a mistake - they must have had a
legitimate reason for it otherwise). Anyway, thanks again.

 

[Jon Skeet [C# MVP]]

Thanks the feedback. In actuality however, that was a quote from Chris Sells
who's probably more widely known in C++ circles (which is my own
background). You can read what he said here if you're interested (just
search for "avoid boxing" and see the paragraph that immediately follows

http://msdn.microsoft.com/library/en-us/dnforms/html/winforms08162002.asp?frame=true

I'm surprised to see Mr Sells making such a comment. I suspect I know
what he means, but it's really badly worded. (It's definitely not
avoiding boxing - it's just doing it at a different point.)

This change breaks existing code however.

Indeed. I don't know why it's been changed, and I can see that relying
on the ordinal is a bit of a pain. On the other hand, I don't think it
was ever *documented* to behave in the way it did previously, so
arguably MS was free to change the behaviour. Anyway, at least you've
got a workaround now.

 

[John Brown]

I'm surprised to see Mr Sells making such a comment. I suspect I know

what he means, but it's really badly worded. (It's definitely not
avoiding boxing - it's just doing it at a different point.)

Actually I don't see it that way at all since [un]boxing is clearly going on
and he must surely know it (I mean, it's plainly obvious). His statement
simply reflects the timing of it. If he assigns to a "bool" directly and
then tries to stuff that into the array, a boxed value will end up in the
array instead of the original bool. So the original bool will never be
updated. I think it's pretty clear then that his use of the term "avoid"
refers to the latter situation, i.e., the "boxing" he refers to is that
which would otherwise occur if he didn't "avoid" it from the get-go (which
his comment therefore refers to notwithstanding his placement of it - right
above the assignment itself which is arguably appropriate given it's an
"object" and not a "bool" for the very reason he cites - his comment is
nevertheless a reflection of the entire situation in general).

Indeed. I don't know why it's been changed, and I can see that relying
on the ordinal is a bit of a pain. On the other hand, I don't think it
was ever *documented* to behave in the way it did previously, so
arguably MS was free to change the behaviour.

Assuming however that the C# language lawyers didn't make this change for
some pressing reason, on the surface it appears broken. My instincts also
tell me that it might violate the C# standard but I'd have to investigate
further (just a "gut" feeling only for now)

Anyway, at least you've got a workaround now.

Yes, thanks again for your assistance (appreciated).

 

[Jon Skeet [C# MVP]]

I'm surprised to see Mr Sells making such a comment. I suspect I know
what he means, but it's really badly worded. (It's definitely not
avoiding boxing - it's just doing it at a different point.)

Actually I don't see it that way at all since [un]boxing is clearly going on
and he must surely know it (I mean, it's plainly obvious). His statement
simply reflects the timing of it. If he assigns to a "bool" directly and
then tries to stuff that into the array, a boxed value will end up in the
array instead of the original bool. So the original bool will never be
updated. I think it's pretty clear then that his use of the term "avoid"
refers to the latter situation, i.e., the "boxing" he refers to is that
which would otherwise occur if he didn't "avoid" it from the get-go (which
his comment therefore refers to notwithstanding his placement of it - right
above the assignment itself which is arguably appropriate given it's an
"object" and not a "bool" for the very reason he cites - his comment is
nevertheless a reflection of the entire situation in general).

It's clear to both of us that the statement below the comment does
boxing, but suppose you weren't confident in your understanding of
boxing - wouldn't you get nervous from such a comment? It could at the
very least be better worded, eg:

// Do boxing up front, so we can keep a reference to the box

Assuming however that the C# language lawyers didn't make this change for
some pressing reason, on the surface it appears broken. My instincts also
tell me that it might violate the C# standard but I'd have to investigate
further (just a "gut" feeling only for now)

This is absolutely *not* part of the C# standard. It's not a language
issue at all - it's an issue in terms of the implementation of
reflection.

Yes, thanks again for your assistance (appreciated).

No problem.

Jon

 

[John Brown]

It's clear to both of us that the statement below the comment does

boxing, but suppose you weren't confident in your understanding of
boxing - wouldn't you get nervous from such a comment? It could at the
very least be better worded, eg:

// Do boxing up front, so we can keep a reference to the box

Agreed but it's really a religious issue. Given his explanation that follows
coupled with the fact that the article itself isn't about boxing (it's just
a side issue), I'm cutting him some slack. I doubt he was analyzing the
issue ad-nauseam at the time

This is absolutely *not* part of the C# standard. It's not a language
issue at all - it's an issue in terms of the implementation of
reflection.

I'll take your word for it since it was only a gut feeling based on many
years in the C/C++ trenches (drawing precedent where perhaps I shouldn't)