.NET 1.1 code using 'is' operator fails on .NET 2.0 .....

I'm surprised it works in 1.1, since a conversion from uint
to int
potentially loses precision. As a rule of thumb, if you
can't implicitly
convert the type (uint -> int), then you can't implicitly
convert the array
type (uint[] -> int[]).

I would expect both long[] and ulong[] to succeed.

On 11/3/06, Hewitt, Simon C. (Contractor)
<Simon.Hewittuk.bp.com> wrote:
>
> Just had a nasty shock trying out a class written for
.NET 1.1 in .NET
> 2.0......
>
> The first thing I noticed was that I got some warnings
about
> CLSCompliant(false) attributes I have set on some
methods - apparently,
> they are not required because I don't have a
CLSCompliant attribute on
> the assembly - fair enough.
>
> Then, several unit tests failed - all variations on the
same theme which
> may or may not be related to the CLSCompliant thing
(although I have now
> added the attribute assembly and get the same issue
with both True and
> False)
>
> Here is another simplified test which shows the
problem:
>
>                 [Test]
>                 public void TestXXX()
>                 {
>                         object testArray = new uint[1];
>                         Assert.IsTrue(testArray is
uint[]);
>                         Assert.IsFalse(testArray is
int[], "This does
> not occur in .NET 1.1");
>                 }
>
> This test passed under .NET 1.1 and failed under .NET
2.0.
>
> Looks like some sort of covariance change to the 'is'
operator but I
> can't find any info on MSDN or Google - anyone come
across this before?
>
> Cheers
> Simon
>
>
> ===================================
> This list is hosted by DevelopMentor(r)  http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com

>



--
Brad Wilson
http://www.
agileprogrammer.com/dotnetguy/
http://www.fl
ickr.com/photos/dotnetguy/

"Time is an illusion; lunchtime, doubly so."

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

> I'm surprised it works in 1.1, since a conversion from
uint to int
> potentially loses precision. As a rule of thumb, if you
can't implicitly
> convert the type (uint -> int), then you can't
implicitly convert the array
> type (uint[] -> int[]).

I' ve just tried it out under 2.0 and the point is that an
indirect
conversion from uint[] to int[] works, i.e. the cast
succeeds and "is"
returns "true" in the following code:

object testArray = new uint[] ;
Console.WriteLine(testArray is int[]); // True
int[] ia = (int[])testArray; // succeeds

On the other hand, a direct conversion is not allowed, the
cast yields
a compile error (CS0030: Cannot convert type 'uint[]' to
'int[]')

uint[] testArray = new uint[] ;
Console.WriteLine(testArray is int[]); // False
int[] ia = (int[])testArray; // compiler error: CS0030

Indeed I think it's strange that the indirect conversion
does work.

Regards,
Fabian

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Brad Wilson wrote:
> I'm surprised it works in 1.1, since a conversion from
uint to int
> potentially loses precision. As a rule of thumb, if you
can't implicitly
> convert the type (uint -> int), then you can't
implicitly convert the array
> type (uint[] -> int[]).
>
> I would expect both long[] and ulong[] to succeed.

I wouldn't expect int[] -> long[] (or to ulong[]) to
succeed as the
element sizes are different.

I believe that int[]/uint[] and long[]/ulong[] working is a
bug on the
part of the MS compilers - they decided not to forbid it
because it
works on the CLR, but I believe that strictly speaking it
shouldn't be
allowed.

I suggest people don't try to rely on it in their code.

Jon

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

On 11/4/06, Fabian Schmied <fabian.schmiedgmx.at> wrote:
> > I'm surprised it works in 1.1, since a conversion
from uint to int
> > potentially loses precision. As a rule of thumb,
if you can't implicitly
> > convert the type (uint -> int), then you can't
implicitly convert the array
> > type (uint[] -> int[]).
>
> I' ve just tried it out under 2.0 and the point is that
an indirect
> conversion from uint[] to int[] works, i.e. the cast
succeeds and "is"
> returns "true" in the following code:
>
> object testArray = new uint[] ;
> Console.WriteLine(testArray is int[]); // True
> int[] ia = (int[])testArray; // succeeds
>
> On the other hand, a direct conversion is not allowed,
the cast yields
> a compile error (CS0030: Cannot convert type 'uint[]'
to 'int[]')
>
> uint[] testArray = new uint[] ;
> Console.WriteLine(testArray is int[]); // False
> int[] ia = (int[])testArray; // compiler error: CS0030
>
> Indeed I think it's strange that the indirect
conversion does work.

I've confirmed the same thing happens in VB.NET and that the
'obvious'
indirect cast works: I.e. this compiles and works:
int[] ia = (int[])(Object)testArray;
(Note I've only done the VB.NET equivalent, so any errors
above are
just my lack of C# usage.)
Regards,
Mark Hurd, B.Sc.(Ma.)(Hons.)

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Why do you think it should fail? This isn't C. 

On 11/5/06, Jon Skeet <skeetpobox.com> wrote:
>
> Brad Wilson wrote:
> > I'm surprised it works in 1.1, since a conversion
from uint to int
> > potentially loses precision. As a rule of thumb,
if you can't implicitly
> > convert the type (uint -> int), then you can't
implicitly convert the
> array
> > type (uint[] -> int[]).
> >
> > I would expect both long[] and ulong[] to succeed.
>
> I wouldn't expect int[] -> long[] (or to ulong[]) to
succeed as the
> element sizes are different.
>
> I believe that int[]/uint[] and long[]/ulong[] working
is a bug on the
> part of the MS compilers - they decided not to forbid
it because it
> works on the CLR, but I believe that strictly speaking
it shouldn't be
> allowed.
>
> I suggest people don't try to rely on it in their code.
>
> Jon
>
> ===================================
> This list is hosted by DevelopMentor�  http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com

>



-- 
Brad Wilson
http://www.
agileprogrammer.com/dotnetguy/
http://www.fl
ickr.com/photos/dotnetguy/

"Time is an illusion; lunchtime, doubly so."

Brad Wilson wrote:
> Why do you think it should fail? This isn't C. 

That's exactly *why* it should fail - it's not unsafe in the
way that C
is. C trusts that if you start using something as a long[],
it's
reasonable: C# makes no such assumptions.

How would you expect an int[] cast to a long[] to behave?
Would you
expect each long to reflect *two* of the entries in the
original array,
or one? If it's two, what would happen if the original array
had an odd
number of elements? Would you expect the Length property to
return
different values based on how you viewed the *same object*?

If you'd expect each long entry to reflect a single entry,
how would you
expect it to behave when pinned and used as a long*? What
would happen
if you tried to assign a value to an element which was
outside the range
of int?

A long[] is represented by contiguous elements in memory,
where each
element is 8 bytes. An int[] is represented by contiguous
elements in
memory, where each element is 4 bytes. The two definitions
just aren't
compatible.

Jon

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com