none
Delegates RRS feed

  • Question

  •  

    I have a lot of questions concerning delegates.

     

    1)     I know that in .NET 1.1, a normal delegate did not have a Previous field, which could be used to link delegates together. Therefore, if you wanted to combine DelegateB with DelegateA, DelegateB was first cloned to a multicast delegate, which has the Previous field. Then the field was set to point to DelegateA. However, I have seen descriptions that this has been changed in .NET 2.0. Now all delegates should inherit from multicast delegates, which inherit from delegates, but if you read the help files they still talk about both delegates and multicast delegates. What is correct? Can you just regard all delegates as multicast delegates?

     

    2)     In the help files you can read that delegates are immutable so if you combine two delegates you get a complete new one with an invocation list equal to the sum of the invocation lists of the two delegates. However, this doesn’t make sense. One delegate cannot hold references to more methods, and I have seen a very detailed description with drawings of the combine operation (http://www.eggheadcafe.com/articles/dotnet_delegates.asp), which shows that it is just a link operation and perhaps a clone operation in case of a delegate without the Previous field. Besides, an invocation list cannot consist of other things than delegates, so why clone all delegates and link them together in a new list? As I see it, the invocation list and the message queue are just some delegates linked together by means of the Previous field. Is this correct?

     

    3)     A delegate is usually regarded as a function pointer with added safety because it has a signature, which much match the arguments of the method to call, but it doesn’t make sense. Why can’t the compiler take care of that as it does in all other cases? I know that unlike a normal call, the method to call may be determined at run time with delegates, but since all possible methods to call are specified in declarations of the delegates (AddressOf MethodToCall), the compiler can just record the arguments needed for these methods and compare them with the arguments supplied in the Invoke or BeginInvoke statement. Besides, a delegate only contain a link to an object, which holds the arguments, so in principle it is possible to link to an object, which does not match the arguments of the method to call – even if the signature matches. Originally I thought that delegates have a storage area to hold the arguments to transfer, so that it would not be necessary to use the heap in case of ByVal. Then it all would make sense, but I know now that delegates only have a single pointer to an object, which holds all arguments, so that in case of more arguments, it is necessary to combine these into a single object.

     

    4)     What if you e.g. want to transfer a data type, which is not an object, to a method like e.g. an Integer? Is it then necessary to box the integer in an object? The help files for some reasons avoid all examples with more than one argument and examples with simple data types like integers, bytes etc.

     

    5)     Why is it necessary with the AdressOf keyword? If you call a normal method, the compiler automatically replaces the name of the method with the address, so why can’t it do the same with delegates?

     

    PS. I usually use VB, but any links and descriptions are very interesting.

     


    Monday, March 19, 2007 8:14 AM