Hi Corneliu/Frans
I decided to separate out Array-type objects from the main
list and then
extract the element type. I can then use a nested
if/then/else to
process the array type accordingly....
...
else if (value is Array)
{
Type elementType =
value.GetType().GetElementType();
writeTypeCode(SerializedType.ValueArrayType);
if (elementType == typeof(Int32))
...
This is working for now and passes all my tests. Also, I
would have to
do something similar for Nullable types I think.
I'll look at your other suggestions though just in case
there is a
faster way.
Cheers
Simon
> -----Original Message-----
> From: Discussion of development on the .NET platform
using
> any managed language [mailto OTNET-CL
R DISCUSS.DEVELOP.COM]
> On Behalf Of Corneliu I. Tusnea
> Sent: 05 November 2006 10:58
> To: DOTNET-CLRDISCUSS.DEVELOP.COM
> Subject: Re: [DOTNET-CLR] .NET 1.1 code using 'is'
operator
> fails on .NET 2.0 .....
>
> Hewitt,
>
> Why not use the TypeCode to detect the base type. Then
use an
> array with
> delegates (function pointers) to find exactly the
method to use for
> serialize/deserialize, or a switch:
>
> TypeCode typeCode = Type.GetTypeCode(
testObject.GetType() );
> switch( typeCode )
> {
> case TypeCode.Boolean:
> [...]
> case TypeCode.Double:
> [...]
> }
>
> AFAIK this is the fastest method you could use.
>
> Regards,
>
> Corneliu I. Tusnea
> Readify | Senior Developer
>
> M: +61 410 835 593 | C: corneliu.tusneareadify.net
>
> -----Original Message-----
> From: Discussion of development on the .NET platform
using any managed
> language [mailtoOTNET-CL
RDISCUSS.DEVELOP.COM] On Behalf Of Hewitt,
> Simon C. (Contractor)
> Sent: Sunday, 5 November 2006 9:14 PM
> To: DOTNET-CLRDISCUSS.DEVELOP.COM
> Subject: Re: [DOTNET-CLR] .NET 1.1 code using 'is'
operator fails on
> .NET 2.0 .....
>
> Thanks to all for the comments.
>
> So since my .NET 1.1 code is now broken in .NET 2.0 and
the nearest
> explanation about covariance shouldn't happen for value
types, should
> this be logged with MS as a bug or a breaking change?
>
> Even so, my code now needs to be tweaked. Basically,
there is a large
> if/elseif statement (faster than a switch) to identify
an
> object looking
> something like this....
>
> else if (value is Int32[])
> {
>
> writeTypeCode(SerializedType.ValueArrayType);
>
> writeTypeCode(SerializedType.Int32Type);
>
writeInt32Array((Int32[]) value);
> }
>
> else if (value is Int16[])
> {
>
> writeTypeCode(SerializedType.ValueArrayType);
>
> writeTypeCode(SerializedType.Int16Type);
>
writeInt16Array((Int16[]) value);
> }
>
> else if (value is Int64[])
> {
>
> writeTypeCode(SerializedType.ValueArrayType);
>
> writeTypeCode(SerializedType.Int64Type);
>
writeInt64Array((Int64[]) value);
> }
>
> else if (value is UInt32[])
> {
>
> writeTypeCode(SerializedType.ValueArrayType);
>
> writeTypeCode(SerializedType.UInt32Type);
>
writeUInt32Array((UInt32[]) value);
> }
>
> .... I still need to be able to determine the *exact*
type of object
> not something it is castable to - any ideas for the
quickest method
> (this is for serialization and needs to be as fast as
possible)??
>
> Cheers
> Simon
>
>
> > -----Original Message-----
> > From: Discussion of development on the .NET
platform using
> > any managed language [mailtoOTNET-CL
RDISCUSS.DEVELOP.COM]
> > On Behalf Of Brad Wilson
> > Sent: 05 November 2006 08:44
> > To: DOTNET-CLRDISCUSS.DEVELOP.COM
> > Subject: Re: [DOTNET-CLR] .NET 1.1 code using 'is'
operator
> > fails on .NET 2.0 .....
> >
> > 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."
> >
>
> ===================================
> This list is hosted by DevelopMentor(r) http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
>
> ===================================
> This list is hosted by DevelopMentor(r) http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
>
===================================
This list is hosted by DevelopMentorŪ http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
|