get the iterator

[Marco]

I need to get a iterator from any generic collection.
public class .... GetIterator(Obj ect collection)
{

.....

}

How can I do this with reflection?

Thanks in advance.

[Tim Haughton]

"Helge Jensen" <he**********@s log.dk> wrote in message
news:43******** ******@slog.dk. ..

Why use "collection as IEnumerable"? If it's supposed to be a collection
just use a cast. What would be a reasonable behaviour if collection is
not IEnumerable?

Helge Jensen
mailto:he****** ****@slog.dk
sip:he********* *@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

Reasonable behaviour is entirely dependent on its context. It's just a code
snippet so reasonable behaviour doesn't really come into it.

But there are technical differences between C style casting and using the
'as' operator. If we define a method...

private void Bob()
{
object obj1 = new Class1();
Class1 class1 = (Class1) obj1;
Class1 class2 = obj1 as Class1;
}

The IL is different for each cast:

..method private hidebysig instance void Bob() cil managed
{
// Code size 21 (0x15)
.maxstack 1
.locals init ([0] object a,
[1] class ClassLibrary2.C lass1 c,
[2] class ClassLibrary2.C lass1 d)
IL_0000: newobj instance void ClassLibrary2.C lass1::.ctor()
IL_0005: stloc.0
IL_0006: ldloc.0
IL_0007: castclass ClassLibrary2.C lass1
IL_000c: stloc.1
IL_000d: ldloc.0
IL_000e: isinst ClassLibrary2.C lass1
IL_0013: stloc.2
IL_0014: ret
} // end of method Class2::Bob

C Style casting uses the castclass opcode which, as you know, throws an
exception if the type atop the stack is not of the desired type. The as
operator uses the isinst opcode instead, returning a null reference in the
event of the type atop the stack not being of the desired types.

There are other considerations of course - the as operator can't use
conversion operators, whereas the C style cast can. The C style cast is
slower than the as operator in success scenarios, and *much* slower than the
as operator in failure scenarios.

I guess the best place for the C style cast is when failure would indicate
an exceptional circumstance.

--
Regards,

Tim Haughton

Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton

[Steve Walker]

In message <43************ **@slog.dk>, Helge Jensen
<he**********@s log.dk> writes

Oliver Sturm wrote:

IEnumerable enumerable = collection as IEnumerable;
if (enumerable != null) {
// get the iterator from enumerable.GetE numerator()
// or just use it directly with foreach
}

Why use "collection as IEnumerable"? If it's supposed to be a
collection just use a cast. What would be a reasonable behaviour if
collection is not IEnumerable?

I've used exactly that approach in a reflection-based data mapping
framework where the behaviour was "if this property is a collection,
iterate and process its members".

--
Steve Walker

[Helge Jensen]

Tim Haughton wrote:

Reasonable behaviour is entirely dependent on its context. It's just a code
snippet so reasonable behaviour doesn't really come into it.
Well, sortof... often there is no reasonable alternative behaviour.

Whether to use "as" of (cast) depends on what behaviour should happen if
collection is not IEnumerable. If you expect the object to actually be
IEnumerable, use a cast. If you have some alternate action if it is not
IEnumerable, as is a very viable option for dispatch.

The must usefull use of as that i've seen if in Equals:

public override bool Equals(object o) {
Foo other = o as Foo;
if ( other == null )
return other;
// continue compare
}

or when you already know that the as conversion will yield non-null:

if ( x is Foo )
(x as Foo).f();
else if ( x is Bar )
(x as Bar).f();
...
C Style casting uses the castclass opcode which, as you know, throws an
exception if the type atop the stack is not of the desired type. The as
operator uses the isinst opcode instead, returning a null reference in the
event of the type atop the stack not being of the desired types.
How does the IL code come into consideration? This is about semantics.
There are other considerations of course - the as operator can't use
conversion operators, whereas the C style cast can. The C style cast is
slower than the as operator in success scenarios, and *much* slower than the
as operator in failure scenarios.
Slower? have you done any tests?

I have a test that shows almost exactly the same performance of the two
casts when successfull, with a *slight* edge to casting (less than 2%).

Certainly the difference between the performance of the operations is
nowhere near high enough to be of any consideration.

The semantics of operations is vastly more important that the
performance, atleast untill performance becomes a problem.

I have a saying i repeat when someone brings this, or foreach vs.
for+index or something other like that up:
"Syntax rarely change performance, but often changes correctness" ;)
I guess the best place for the C style cast is when failure would indicate
an exceptional circumstance.

Yes, but I formulate that the other way around, "rather CastException
now than unexpected behaviour or NullException later". Of course, if you
really *can* do something with the object, even if it's not of the
expected type, using as is fine (and proper).

What I don't want to see is code like:

void f(object x) {
Foo y = x as y;
y.f();
}

Which discards the very usefull info that infact x was not convertible
to y, and instead generates a NullException.

or, the programmer who have heard "as" performs better than casting:

void f(object x) {
Foo y = x as y;
if ( y == null )
throw new SomeException()
}

or, even worse, the surprising semantics of
"default-do-nothing-to-be-flexible"

void f(object x) {
Foo y = x as y;
if ( y != null ) {
// fine and dandy, operations
...
} else {
// What can we do here? ignore
}
}

Which I have seen a few times. This clearly shows a spot where a cast
should have been used. Now, a callers type-mistake is silently ignored!

--
Helge Jensen
mailto:he****** ****@slog.dk
sip:he********* *@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

[Tim Haughton]

"Helge Jensen" <he**********@s log.dk> wrote in message
news:ep******** ******@TK2MSFTN GP15.phx.gbl...

There are other considerations of course - the as operator can't use
conversion operators, whereas the C style cast can. The C style cast is
slower than the as operator in success scenarios, and *much* slower than the as operator in failure scenarios.
Slower? have you done any tests?

Like I'd have the time ;)

I'm of course relying on Microsoft's recomendations. I'm fairly sure they
tested it.
I have a test that shows almost exactly the same performance of the two
casts when successfull, with a *slight* edge to casting (less than 2%).

Certainly the difference between the performance of the operations is
nowhere near high enough to be of any consideration.

The semantics of operations is vastly more important that the
performance, atleast untill performance becomes a problem.

I whole heartedly agree.

[snip]

Your other comments regarding exceptions, casting and so on are fine in the
scope of general object oriented development. And I'll almost always rather
my code express intent than be super optimised. But your original question
was "Why use "collection as IEnumerable"? ", a question set in the C# arena,
and my answer was in the same arena.

Well, using the 'as' operator more clearly expresses intent than C style
casting IMHO. It's also faster than C style casting (according to MS) in
versions 1.0 and 1.1 of the CLR, I haven't checked to see if this is still
the case in 2.0.

In the real world, it doesn't make a huge difference, but hey - you asked :)

--
Regards,

Tim Haughton

Agitek
http://agitek.co.uk
http://blogitek.com/timhaughton

[Helge Jensen]

It's also faster than C style casting (according to MS) in
versions 1.0 and 1.1 of the CLR, I haven't checked to see if this is still
the case in 2.0.

In the real world, it doesn't make a huge difference, but hey - you asked :)

Real-world performance is meaured in the real-world, not in
MS-recomendations :)

under .NET-1.1:

count: 100000000, as : 00:00:02.513614 4, cast: 00:00:02.443513 6,
slower: -2,79 %
count: 1000000000, as : 00:00:25.076057 6, cast: 00:00:24.294934 4,
slower: -3,12 %
Press ENTER

namespace cast_test
{
public class CastTest
{
class Foo {};
class Bar: Foo {}
class Baz: Foo {};
object[] copyfrom = { new Bar(), new Baz() };
object[] copyto = { null, null };
public void test(int count)
{
// Ready for test
DateTime start_as = DateTime.Now;
for ( int i = 0; i < count; ++i )
copyto[i%2] = copyfrom[i%2] as Foo;
DateTime end_as = DateTime.Now;
for ( int i = 0; i < count; ++i )
copyto[i%2] = (Foo)copyfrom[i%2];
DateTime end_cast = DateTime.Now;

TimeSpan time_as = end_as - start_as;
TimeSpan time_cast = end_cast - end_as;
TimeSpan cast_slower = time_cast - time_as;

Console.WriteLi ne("count: {0}, as : {1}, cast: {2}, slower:
{3:p}", count, time_as, time_cast, cast_slower.Tot alMilliseconds /
time_as.TotalMi lliseconds);
}
public static void Main()
{
CastTest t = new CastTest();
int[] counts = { 100000000, 1000000000 };
foreach ( int count in counts )
t.test(count);
bool readline = !System.Diagnos tics.Debugger.I sAttached;
#if !DEBUG
readline = true;
#endif
if ( readline )
{
Console.WriteLi ne("Press ENTER");
Console.Read();
}
}
}
}
--
Helge Jensen
mailto:he****** ****@slog.dk
sip:he********* *@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

[Oliver Sturm]

Helge Jensen wrote:

It's also faster than C style casting (according to MS) in
versions 1.0 and 1.1 of the CLR, I haven't checked to see if this is still
the case in 2.0.

In the real world, it doesn't make a huge difference, but hey - you asked
:)

Real-world performance is meaured in the real-world, not in
MS-recomendations :)

under .NET-1.1:

count: 100000000, as : 00:00:02.513614 4, cast: 00:00:02.443513 6, slower:
-2,79 %
count: 1000000000, as : 00:00:25.076057 6, cast: 00:00:24.294934 4, slower:
-3,12 %

I don't know about MS saying that "as" is faster - I think both "as" and
casts have their practical use and I would have assumed casts to be
faster, simply because they have less to do.

If I know an object to be of the type I want it to be, only due to the
flow of things I don't have a reference of that type at the moment, I use
a cast to get that reference. But if I'm not sure whether an object has
the type (or implements the interface) I'm looking for, I have to find
out, and there are two ways of doing that: (1) using "is", followed by a
cast and (2) using "as" and compare to null - AFAIK (2) is a lot faster
here, and it's also cleaner to read. Small wonder it should be a bit
slower than the cast alone; after all, you get the same functionality that
the "is + cast" combination offers.

As I was saying, I don't usually use casts all that much. Normally, when I
know an object to be of a specific type, I'll probably already have a
reference of that specific type, so I don't need to cast one. This sounds
like part of the discussion "coding to an interface vs. coding to an
implementation" to me - if you find yourself doing casts all the time,
maybe you should ask yourself why you're passing around interfaces (in the
general, not the C# sense of the word) but apparently writing a lot of
code that's implementation specific. Using "as" here and there to code
optional behaviour, especially when dealing with interfaces (in the C#
sense of the word this time), sounds like a much better idea to me.
Oliver Sturm
--
Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)

[Helge Jensen]

Oliver Sturm wrote:

Helge Jensen wrote: I don't know about MS saying that "as" is faster - I think both "as" and
casts have their practical use and I would have assumed casts to be
faster, simply because they have less to do.
Perhaps you confused my post with Tim's? I explicitly said:

"Certainly the difference between the performance of the operations is
nowhere near high enough to be of any consideration. "

I am not really interested in discussed if X is faster than Y, but I am
provoked by statements like "X is faster than Y, so I use X". Especially
when I know the two to be semanticly different and the performance
difference to be neglicible.
find out, and there are two ways of doing that: (1) using "is", followed
by a cast and (2) using "as" and compare to null - AFAIK (2) is a lot
faster here, and it's also cleaner to read. Small wonder it should be a
bit slower than the cast alone; after all, you get the same
functionality that the "is + cast" combination offers.
I still (slightly) prefer writing type-dispatch as:

if ( x is Foo )
(x as Foo).f();
else if ...

Since it reads easier than:

if ( x is Foo )
((Foo)x).f();
else if ...

I don't think i have a single place where I will notice (if there is
one, the compiler could easily rewrite one to the other) performance
difference.
This
sounds like part of the discussion "coding to an interface vs. coding to
an implementation" to me - if you find yourself doing casts all the
time, maybe you should ask yourself why you're passing around interfaces
(in the general, not the C# sense of the word) but apparently writing a
lot of code that's implementation specific. Using "as" here and there to
code optional behaviour, especially when dealing with interfaces (in the
C# sense of the word this time), sounds like a much better idea to me.

I don't think anyone was talking about casting "all the time", I ain't
anyway.

--
Helge Jensen
mailto:he****** ****@slog.dk
sip:he********* *@slog.dk
-=> Sebastian cover-music: http://ungdomshus.nu <=-

[Oliver Sturm]

Helge Jensen wrote:

I don't know about MS saying that "as" is faster - I think both "as" and
casts have their practical use and I would have assumed casts to be
faster, simply because they have less to do.

Perhaps you confused my post with Tim's? I explicitly said:

"Certainly the difference between the performance of the operations is
nowhere near high enough to be of any consideration. "

I am not really interested in discussed if X is faster than Y, but I am
provoked by statements like "X is faster than Y, so I use X". Especially
when I know the two to be semanticly different and the performance
difference to be neglicible.

Sorry, I was more or less commenting on the complete discussion lead by
you two.

find out, and there are two ways of doing that: (1) using "is", followed
by a cast and (2) using "as" and compare to null - AFAIK (2) is a lot
faster here, and it's also cleaner to read. Small wonder it should be a
bit slower than the cast alone; after all, you get the same functionality
that the "is + cast" combination offers.

I still (slightly) prefer writing type-dispatch as:

if ( x is Foo )
(x as Foo).f();
else if ...

Since it reads easier than:

if ( x is Foo )
((Foo)x).f();
else if ...

And I'll use this form, which I find even more readable and which is
probably the most performant at the same time:

Foo foo = x as Foo;
if (foo != null)
foo.f();
...

Which was really the starting point of the whole discussion, wasn't it?
Oliver Sturm
--
Expert programming and consulting services available
See http://www.sturmnet.org (try /blog as well)

[Joanna Carter \(TeamB\)]

"Marco" <te******@yahoo .com> a écrit dans le message de news:
11************* *********@g44g2 00...legr oups.com...

I need to get a iterator from any generic collection.
public class .... GetIterator(Obj ect collection)
{

....

}

How can I do this with reflection?

You shouldn't need reflection, just check if the object supports IEnumerable
and then cast it to IEnumerable and call GetEnumerator.

Joanna

--
Joanna Carter
Consultant Software Engineer