It's a loophole isn't it?

[teguh123]

Public Shared Sub ExecuteThread(ByVal PackedScannableParameter As String, ByVal theFarm As enchancedWinClient)
        theFarm.PackedScannable = PackedScannableParameter
        theFarm.Thread = New System.Threading.Thread(Sub() beginThreadAction.Invoke(PackedScannableParameter, theFarm))
        theFarm.Thread.Start()
    End Sub

The function system.threading.thread constructor takes a delegate that accept no argument. My delegate, beginThreadAction accepts 2 arguments. I just shoehorn it with lamda expression.

How does that really work is beyond me. It's working though.

[jmcilhinney]

It works because the method you're using as the entry point for your thread has no parameters. This:

Sub() beginThreadAction.Invoke(PackedScannableParameter, theFarm)

is the method that starts the thread. In that method you call another method. That code is just like this:

Private Sub SomeMethod()
    beginThreadAction.Invoke(PackedScannableParameter, theFarm)
End Sub

As you can see, that SomeMethod method has no parameters, and that's just what you're doing.

[teguh123]

With one small catch JM,

Private Sub SomeMethod()
    beginThreadAction.Invoke(PackedScannableParameter, theFarm)
End Sub

How the hell SomeMethod knows the value of PackedScannableParameter,theFarm that's the whole point of having parameter in the first place isn't it?



I understand Jmcilhinney. I am still amazed. In C++ you can't do this sort of thing with function pointer. You can't can you?

Also this so called parameterless sub somehow "knows" the value of PackedScannableParameter, theFarm being fed to it. So there are several ways to pass values to function. The obvious tell tale is parameter.

But wait, the sub function has NO parameter. Yet it knows the value of 2 objects based on context. Looks like lamda delegate must have treated all the local variable on the function where it's declared as some form of semi global variable.

Also by the time the thread are actually started, the stack that create the lamda expression already disappear. So implementing this by having the delegate to contain an address of the stack wouldn't work.

It's just amazing. I use vb.net but when I go back to C++ I want to program in C++ like I do in vb.net. With smart pointers and stuff. I think many options exist in standard library.

No wonder microsoft makes awesome program. Man. VB.net is awesome.

[Evil_Giraffe]

It's called a closure. PackedScannableParameter and theFarm are "hoisted" variables. Basically, a class is generated behind the scenes that has a reference back to those two variables. It's nothing you couldn't write by hand if you so desired (and had plenty of time )

[jmcilhinney]

With one small catch JM,

Private Sub SomeMethod()
    beginThreadAction.Invoke(PackedScannableParameter, theFarm)
End Sub

How the hell SomeMethod knows the value of PackedScannableParameter,theFarm that's the whole point of having parameter in the first place isn't it?

Yes, obviously lambda expressions are a bit different to named methods. I wasn't trying to say that you could substitute one for the other. I was trying to point out that the method you are using as the entry point for the thread has no parameters, which is why it works. You're passing arguments to a method called within the entry method, not to the entry method itself. That is the point I was trying to make because that is what you said you didn't understand.

I do agree that .NET does have many very cool features.

[teguh123]

It's called a closure. PackedScannableParameter and theFarm are "hoisted" variables. Basically, a class is generated behind the scenes that has a reference back to those two variables. It's nothing you couldn't write by hand if you so desired (and had plenty of time )

Thanks Evil and JM. I long suspected that those delegates are way beyond just function pointer. You can't do this in C++ can you? In C++ you need a special class, use functor. Hell, there is no lamda expression in C++ anyway.

So hoisted variable, closure, where can I learn more about that? Google?

Genius. Pure genius. I don't even know how it works. I just have faith on the magic of managed code. Sigh... Soon I'll program for iphone using C++ again.

This vb.net is ubber C++. Bjarn Stroustrope has shoes to fill.

[teguh123]

Also if you look at http://www.codeproject.com/KB/cpp/FastDelegate.aspx and http://www.parashift.com/c++-faq-lit....html#faq-33.1 you see that in C++ pointer to function and pointer to a member function is a completely different animal.

Pointer to a member function has a hidden this pointer. In vb.net, somehow there is something complex sweeped under the rug.

I suppose, typical delegate not only knows the address of the function but also have a this pointer. But where do this "this" pointer points to? An A class? A B class, a C class? or null? That must be determined at run time rather than compile time isn't it?

There has to be some form of run time dynamic cast typing there.