Thread overview | |||||||||
---|---|---|---|---|---|---|---|---|---|
|
January 13, 2006 Delegate/Function Pointers | ||||
---|---|---|---|---|
| ||||
Ok... I get the point that one can use a delegate to refer to a non-static member function (i.e. as non-static function of a class or struct) and a function pointer to refer to all other functions (i.e., static members of class and struct, and non-members). What I don't understand however, is at what point in more advantageous to use a pointer or a deligate vice a standard function call. Why would I need to point to a function when I can call it outright? Is there a time when a delegate or pointer is the only viable means of accomplishing something? In those cases where a pointer or a deligate is the preferred method: why would it be so? Is it just a matter of taste? Thanks in advance, Andrew |
January 13, 2006 Re: Delegate/Function Pointers | ||||
---|---|---|---|---|
| ||||
Posted in reply to tyro [a.c.edwards] | tyro [a.c.edwards] wrote:
> Ok...
>
> I get the point that one can use a delegate to refer to a non-static member
> function (i.e. as non-static function of a class or struct) and a function
> pointer to refer to all other functions (i.e., static members of class and
> struct, and non-members). What I don't understand however, is at what point in
> more advantageous to use a pointer or a deligate vice a standard function call.
>
> Why would I need to point to a function when I can call it outright? Is there a
> time when a delegate or pointer is the only viable means of accomplishing
> something? In those cases where a pointer or a deligate is the preferred method:
> why would it be so? Is it just a matter of taste?
I can think of two related scenarios to use function pointers. First, they can be useful when you want to be able to re-use the same piece of code in a number of slightly different ways... particularly if you want the user to be able to specify this. For example:
void print( bit delegate( out char ) getChar )
{
char c;
while( getChar( c ) )
{
putchar( c );
}
}
The delegate passed to the print function above may get its data from a file, from a string, from a socket, etc, but the same print function can be used in each case.
The second scenario is that sometimes you just don't know what function you want to execute at design-time. Think of it like polymorphism at the function level. You might have a state machine that spits out different function pointers at different times during its execution, and these pointers may be passed to other functions to perform some operation. Class-level polymorphism can often be used in these cases as well, but if you only ever want to execute a function with a given signature then there's no reason to design a class heirarchy for this purpose--particularly with delegates as they have access to stack data (which makes them a bit like function objects--functors--in C++).
Sean
|
January 13, 2006 Re: Delegate/Function Pointers | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | In article <dq8d66$ogg$1@digitaldaemon.com>, Sean Kelly says... > >tyro [a.c.edwards] wrote: >> Ok... >> >> I get the point that one can use a delegate to refer to a non-static member function (i.e. as non-static function of a class or struct) and a function pointer to refer to all other functions (i.e., static members of class and struct, and non-members). What I don't understand however, is at what point in more advantageous to use a pointer or a deligate vice a standard function call. >> >> Why would I need to point to a function when I can call it outright? Is there a time when a delegate or pointer is the only viable means of accomplishing something? In those cases where a pointer or a deligate is the preferred method: why would it be so? Is it just a matter of taste? > >I can think of two related scenarios to use function pointers. First, they can be useful when you want to be able to re-use the same piece of code in a number of slightly different ways... particularly if you want the user to be able to specify this. For example: > > >void print( bit delegate( out char ) getChar ) >{ > char c; > while( getChar( c ) ) > { > putchar( c ); > } >} So in this regard I don't have to know the actual name of the function being called prior to implementing my own? > >The delegate passed to the print function above may get its data from a file, from a string, from a socket, etc, but the same print function can be used in each case. but I could achieve the same from a direct function call and still not know it's implementation: # void main() # { # print(); # } # # static char[] str="Test"; # # bit getChar(out char c) # { # if(str.length > 0) # { # c = str[0]; # str = str[1 .. $]; # return true; # } # return false; # } # # void print() # { # char c; # while( getChar( c ) ) # { # writef( c ); # } # } as long as the function I call modifies a char argument and returns a bit the result is the same. So what, other than the fact with the pointer I don't know the function name beforehand, makes the use of the pointer that much better? >The second scenario is that sometimes you just don't know what function you want to execute at design-time. Think of it like polymorphism at the function level. You might have a state machine that spits out different function pointers at different times during its execution, and these pointers may be passed to other functions to perform some operation. Class-level polymorphism can often be used in these cases as well, but if you only ever want to execute a function with a given signature then there's no reason to design a class heirarchy for this purpose--particularly with delegates as they have access to stack data (which makes them a bit like function objects--functors--in C++). > Ok... this I can understand. Still having a dificulty grasping the first scenario though. Not that I don't understand what it does. Just why it would be necessary. >Sean |
January 13, 2006 Re: Delegate/Function Pointers | ||||
---|---|---|---|---|
| ||||
Posted in reply to tyro [a.c.edwards] | tyro [a.c.edwards] wrote: > In article <dq8d66$ogg$1@digitaldaemon.com>, Sean Kelly says... > >>tyro [a.c.edwards] wrote: >> >>>Ok... >>> >>>I get the point that one can use a delegate to refer to a non-static member >>>function (i.e. as non-static function of a class or struct) and a function >>>pointer to refer to all other functions (i.e., static members of class and >>>struct, and non-members). What I don't understand however, is at what point in >>>more advantageous to use a pointer or a deligate vice a standard function call. >>> >>>Why would I need to point to a function when I can call it outright? Is there a >>>time when a delegate or pointer is the only viable means of accomplishing >>>something? In those cases where a pointer or a deligate is the preferred method: >>>why would it be so? Is it just a matter of taste? >> >>I can think of two related scenarios to use function pointers. First, they can be useful when you want to be able to re-use the same piece of code in a number of slightly different ways... particularly if you want the user to be able to specify this. For example: >> >> >>void print( bit delegate( out char ) getChar ) >>{ >> char c; >> while( getChar( c ) ) >> { >> putchar( c ); >> } >>} > > > So in this regard I don't have to know the actual name of the function being > called prior to implementing my own? > > >>The delegate passed to the print function above may get its data from a file, from a string, from a socket, etc, but the same print function can be used in each case. > > > but I could achieve the same from a direct function call and still not know it's > implementation: > > # void main() > # { > # print(); > # } > # # static char[] str="Test"; > # # bit getChar(out char c) > # { > # if(str.length > 0) > # { > # c = str[0]; > # str = str[1 .. $]; > # return true; > # } > # return false; > # } > # # void print() > # { > # char c; > # while( getChar( c ) ) > # { > # writef( c ); > # } > # } > > as long as the function I call modifies a char argument and returns a bit the > result is the same. So what, other than the fact with the pointer I don't know > the function name beforehand, makes the use of the pointer that much better? > > >>The second scenario is that sometimes you just don't know what function you want to execute at design-time. Think of it like polymorphism at the function level. You might have a state machine that spits out different function pointers at different times during its execution, and these pointers may be passed to other functions to perform some operation. Class-level polymorphism can often be used in these cases as well, but if you only ever want to execute a function with a given signature then there's no reason to design a class heirarchy for this purpose--particularly with delegates as they have access to stack data (which makes them a bit like function objects--functors--in C++). >> > > > Ok... this I can understand. Still having a dificulty grasping the first > scenario though. Not that I don't understand what it does. Just why it would be > necessary. > > >>Sean > > > Its certainly not the most common use, but delegates to inner functions allow second order recursion: http://www.latrobe.edu.au/philosophy/phimvt/s00bok.html (begin around Chapter 7 or 8, its heady stuff but very cool) -DavidM |
January 13, 2006 Re: Delegate/Function Pointers | ||||
---|---|---|---|---|
| ||||
Posted in reply to tyro [a.c.edwards] | tyro [a.c.edwards] wrote: > In article <dq8d66$ogg$1@digitaldaemon.com>, Sean Kelly says... >> tyro [a.c.edwards] wrote: >>> Ok... >>> >>> I get the point that one can use a delegate to refer to a non-static member >>> function (i.e. as non-static function of a class or struct) and a function >>> pointer to refer to all other functions (i.e., static members of class and >>> struct, and non-members). What I don't understand however, is at what point in >>> more advantageous to use a pointer or a deligate vice a standard function call. >>> >>> Why would I need to point to a function when I can call it outright? Is there a >>> time when a delegate or pointer is the only viable means of accomplishing >>> something? In those cases where a pointer or a deligate is the preferred method: >>> why would it be so? Is it just a matter of taste? >> I can think of two related scenarios to use function pointers. First, they can be useful when you want to be able to re-use the same piece of code in a number of slightly different ways... particularly if you want the user to be able to specify this. For example: >> >> >> void print( bit delegate( out char ) getChar ) >> { >> char c; >> while( getChar( c ) ) >> { >> putchar( c ); >> } >> } > > So in this regard I don't have to know the actual name of the function being > called prior to implementing my own? > >> The delegate passed to the print function above may get its data from a file, from a string, from a socket, etc, but the same print function can be used in each case. > > but I could achieve the same from a direct function call and still not know it's > implementation: > > # void main() > # { > # print(); > # } > # # static char[] str="Test"; > # # bit getChar(out char c) > # { > # if(str.length > 0) > # { > # c = str[0]; > # str = str[1 .. $]; > # return true; > # } > # return false; > # } > # # void print() > # { > # char c; > # while( getChar( c ) ) > # { > # writef( c ); > # } > # } > > as long as the function I call modifies a char argument and returns a bit the > result is the same. So what, other than the fact with the pointer I don't know > the function name beforehand, makes the use of the pointer that much better? > >> The second scenario is that sometimes you just don't know what function you want to execute at design-time. Think of it like polymorphism at the function level. You might have a state machine that spits out different function pointers at different times during its execution, and these pointers may be passed to other functions to perform some operation. Class-level polymorphism can often be used in these cases as well, but if you only ever want to execute a function with a given signature then there's no reason to design a class heirarchy for this purpose--particularly with delegates as they have access to stack data (which makes them a bit like function objects--functors--in C++). >> > > Ok... this I can understand. Still having a dificulty grasping the first > scenario though. Not that I don't understand what it does. Just why it would be > necessary. For a more complex example, look at my readf implementation available here: http://www.home.f4.ca/sean/d/ (It's the "stdio addon - includes unformat and readf" link) Basically, I pass different getChar delegates to the low-level implementation so I can use the same parser regardless of the input source. Other designs are obviously possible, but this one seemed the most straightforward at the time. Sean |
January 13, 2006 Re: Delegate/Function Pointers | ||||
---|---|---|---|---|
| ||||
Posted in reply to tyro [a.c.edwards] | tyro [a.c.edwards] wrote:
> Ok...
>
> I get the point that one can use a delegate to refer to a non-static member function (i.e. as non-static function of a class or struct) and a function pointer to refer to all other functions (i.e., static members of class and struct, and non-members). What I don't understand however, is at what point in more advantageous to use a pointer or a deligate vice a standard function call.
>
> Why would I need to point to a function when I can call it outright? Is there a time when a delegate or pointer is the only viable means of accomplishing something? In those cases where a pointer or a deligate is the preferred method: why would it be so? Is it just a matter of taste?
>
> Thanks in advance,
> Andrew
The callback pattern is quite common in libraries were you want to provide the application an easy way to handle events. The application can register a function pointer/delegate with the library for a given event. When that event happens, for example a user clicks on some part of the GUI, the registered function is fired, doing something funky in the application, maybe saving a document or something entirely different.
Lars Ivar Igesund
|
January 13, 2006 Re: Delegate/Function Pointers | ||||
---|---|---|---|---|
| ||||
Posted in reply to tyro [a.c.edwards] | the standard C "function-pointer" permits a level of indirection that can be useful for certain types and styles of programming. The D 'function' is identical to a C function-pointer, while the D 'delegate' goes one further: it permits a developer to associate arbitrary "state" with the traditional C function-pointer (the class or struct attributes associated with the delegate function itself). Thus they are both a means of indirection (or function level polymorphism, as Sean noted). "tyro [a.c.edwards]" <tyro_member@pathlink.com> wrote in message news:dq8bqm$n75$1@digitaldaemon.com... > Ok... > > I get the point that one can use a delegate to refer to a non-static > member > function (i.e. as non-static function of a class or struct) and a function > pointer to refer to all other functions (i.e., static members of class and > struct, and non-members). What I don't understand however, is at what > point in > more advantageous to use a pointer or a deligate vice a standard function > call. > > Why would I need to point to a function when I can call it outright? Is > there a > time when a delegate or pointer is the only viable means of accomplishing > something? In those cases where a pointer or a deligate is the preferred > method: > why would it be so? Is it just a matter of taste? > > Thanks in advance, > Andrew > > |
Copyright © 1999-2021 by the D Language Foundation