By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,301 Members | 1,741 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,301 IT Pros & Developers. It's quick & easy.

function pointers

P: n/a
Can anyone tell me the advantages of using function pointers?

Thanks in advance.

Jan 20 '06 #1
Share this Question
Share on Google+
18 Replies


P: n/a
ramu said:
Can anyone tell me the advantages of using function pointers?


They're very handy when you need to point to functions.

Take a look at qsort and bsearch, in the standard library. How do you think
they manage to process any kind of array without knowing what kind of array
it is or which way up you like your data? (And bear in mind that it might
be an array of structs, and qsort has no idea what criteria you use to
determine which way round two structs should be ordered.)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jan 20 '06 #2

P: n/a
ramu wrote:
Can anyone tell me the advantages of using function pointers?

Advantages over what?

Where do you want to use them and what to you intend to gain?

--
Ian Collins.
Jan 20 '06 #3

P: n/a
Richard Heathfield wrote:
ramu said:
Can anyone tell me the advantages of using function pointers?


They're very handy when you need to point to functions.

Take a look at qsort and bsearch, in the standard library. How do
you think they manage to process any kind of array without knowing
what kind of array it is or which way up you like your data? (And
bear in mind that it might be an array of structs, and qsort has
no idea what criteria you use to determine which way round two
structs should be ordered.)


They allow chunks of code to be easily customized to an
application. In the case of my hashlib when the table is created
it is passed five functions, of four different types, that totally
customize the hash table to the application.

You can see the code in question at:

<http://cbfalconer.home.att.net/download/hashlib.zip>

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Jan 20 '06 #4

P: n/a
Ok. Let me put it in this way. At what situations can we use function
pointers?
Regards
Ian Collins wrote:
ramu wrote:
Can anyone tell me the advantages of using function pointers?

Advantages over what?

Where do you want to use them and what to you intend to gain?

--
Ian Collins.


Jan 20 '06 #5

P: n/a

"ramu" <ra******@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
Can anyone tell me the advantages of using function pointers?

Thanks in advance.


Yes, there are a number of typical uses. A common one would be for the
action to be taken when a menu item is selected. Your code has a array of
generic menu structures each of which has an action associated with the menu
item. You can store a function pointer in the array and then use the same
code to call the appropriate function for that menu item. Another one is
when you have an address for a function outside your application space and
need to call the function. This is useful for calling the BIOS reset in RM
DOS. The ability to do this is environment specific. Another one, similar
to the menu action, would be a table of addresses of ISRs, perhaps to be
used to setup a bunch of GDT/IDT selectors. Typically, internal operating
system filesystem structures use pointers to the various file routines.
This allows a single structure to support different filesystems using
different functions with the same structure (similar to menu's).

//Boot OW1.3 code
void (__far *reset)();
reset=MK_FP(0xFFFF,0x0000);
(*reset)(); /* call the function */

//ISR's DJGPP snippet
typedef void(*isr_func)(void);
isr_func isrs[]={
isr00,isr01,isr02, /*etc... */, isrff
};
// use isrs[x] as address for GDT/IDT setup

//menu items DJGPP snippet
typedef struct {
int bogus1;
int bogus2;
int (* action)();
} menu_item;
typedef struct {
int name;
int x,y; // coordinates
menu_item item[32];
} menu;
menu my_menus[]={
{ 0,0, function1} // 'int *function1(void) must exist somewhere...
{ 2,2, function2} // ditto
}
(*my_menus[0].menu_item[6].action)(void); // sixth menu item on menu 0,
which is 'int *function1(void)'
Rod Pemberton
Jan 20 '06 #6

P: n/a
ramu wrote:
Ok. Let me put it in this way. At what situations can we use function
pointers?


Whenever a function pointer is expected?

When the code needs to perform some action, but that action is not
(perhaps cannot, perhaps should not be) known in advance.

--
Chris "understanding is a three-edged sword" Dollin
Jan 20 '06 #7

P: n/a
ramu wrote:
Ok. Let me put it in this way. At what situations can we use function
pointers?


One example that springs to mind is a protocol stack or a driver API
where each module is required to provide a number of entry points
defined in a struct.

For example,

given an interface defined as:

struct DiverInterface
{
void (*initFn)(void);
int (*readFn)( void*, unsigned );
int (*writeFn)( const void*, unsigned );
};

Somewhere in your code:

extern void myInit(void);
extern int myRead( void*, unsigned );
extern int myWrite( const void*, unsigned );

void init(void)
{
struct DiverInterface interface;

interface.initFn = myInit;
interface.readFn = myRead;
interface.writeFn = myWrite;

/* pass to API */
}

--
Ian Collins.
Jan 20 '06 #8

P: n/a
ramu <ra******@gmail.com> wrote:
Can anyone tell me the advantages of using function pointers?


Think of functions (algorithms) as your data. Answer yourself why you
use variables in your programs. For the same reason you use function
pointers - they are variables that hold your functions as data (well,
actually they only hold references - but that's only how far you can get
with the C language). In some languages, but not in C, (some) functions
(or generally code) are objects, and you can pass them around and do
operations on them as operands.

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`
Jan 20 '06 #9

P: n/a
"S.Tobias" wrote:

ramu <ra******@gmail.com> wrote:
Can anyone tell me the advantages of using function pointers?


Think of functions (algorithms) as your data. Answer yourself why you
use variables in your programs. For the same reason you use function
pointers - they are variables that hold your functions as data (well,
actually they only hold references - but that's only how far you can get
with the C language). In some languages, but not in C, (some) functions
(or generally code) are objects, and you can pass them around and do
operations on them as operands.

A function pointer is also needed to register a function with the
atexit() function. A function name used without parentheses
or parameter list...*is* a function pointer. So in some sense, any
time you invoke a function, you are "using" a function pointer.

--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
Jan 21 '06 #10

P: n/a
ramu a écrit :
Can anyone tell me the advantages of using function pointers?


generic programming, events, plug-ins...

--
A+

Emmanuel Delahaye
Jan 21 '06 #11

P: n/a
Charles Richmond a écrit :
A function pointer is also needed to register a function with the
atexit() function. A function name used without parentheses
or parameter list...*is* a function pointer. So in some sense, any
time you invoke a function, you are "using" a function pointer.


ITYM a 'function pointer constant', just like the name of an array is a
'pointer constant'. A 'pointer' is definitely a variable:

/* p is a pointer */
char *p = "hello";
int *p = malloc(sizeof *p * 2);
void f(char *p);

/* x is a[n object] pointer constant */
#define x NULL
char x[] = "hello";
int x[123];

x();

--
A+

Emmanuel Delahaye
Jan 21 '06 #12

P: n/a
Charles Richmond <ri******@comcast.net> wrote:
"S.Tobias" wrote:
ramu <ra******@gmail.com> wrote:
> Can anyone tell me the advantages of using function pointers?


Think of functions (algorithms) as your data. Answer yourself why you
use variables in your programs. For the same reason you use function
pointers - they are variables that hold your functions as data (well,
actually they only hold references - but that's only how far you can get
with the C language). In some languages, but not in C, (some) functions
(or generally code) are objects, and you can pass them around and do
operations on them as operands.

A function pointer is also needed to register a function with the
atexit() function. A function name used without parentheses
or parameter list...*is* a function pointer. So in some sense, any
time you invoke a function, you are "using" a function pointer.

That's right; even a function identifier *with* parentheses is first
converted to pointer to function. But there's an ambiguity in the spoken
language where "pointer" means "a value" (your and Standard's usage) and
"a variable of pointer type" (which is what I, and presumably OP, meant).
What I tried to explain to OP is that the reasons for using variables
of type pointer to function become more obvious once you start to treat
functions (only conceptually) as objects.

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`
Jan 21 '06 #13

P: n/a
S.Tobias a écrit :
But there's an ambiguity in the spoken
language where "pointer" means "a value" (your and Standard's usage) and
"a variable of pointer type" (which is what I, and presumably OP, meant).


This 'value' is clearly an address.

- A pointer is an object. It has an address and a value.
- The value of a pointer is an address or NULL.
- A pointer constant has a value but no address. (Constant expression)
- The value of a pointer constant is an address or NULL.

--
A+

Emmanuel Delahaye
Jan 21 '06 #14

P: n/a
Emmanuel Delahaye <em***@YOURBRAnoos.fr> writes:
S.Tobias a écrit :
But there's an ambiguity in the spoken
language where "pointer" means "a value" (your and Standard's usage) and
"a variable of pointer type" (which is what I, and presumably OP, meant).


This 'value' is clearly an address.

- A pointer is an object. It has an address and a value.
- The value of a pointer is an address or NULL.
- A pointer constant has a value but no address. (Constant expression)
- The value of a pointer constant is an address or NULL.


Sure, using the unqualified word "pointer" only to refer to pointer
objects and using "address" to refer to pointer values, make sense.
Unfortunately, it's not what the standard does. For example, the
description of malloc() says:

The malloc function returns either a null pointer or a pointer to
the allocated space.

So I'm afraid we're stuck with the ambiguity.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jan 21 '06 #15

P: n/a
Keith Thompson wrote:
Emmanuel Delahaye <em***@YOURBRAnoos.fr> writes:
S.Tobias a écrit :
But there's an ambiguity in the spoken
language where "pointer" means "a value" (your and Standard's usage) and
"a variable of pointer type" (which is what I, and presumably OP, meant).


This 'value' is clearly an address.

- A pointer is an object. It has an address and a value.
- The value of a pointer is an address or NULL.
- A pointer constant has a value but no address. (Constant expression)
- The value of a pointer constant is an address or NULL.

Sure, using the unqualified word "pointer" only to refer to pointer
objects and using "address" to refer to pointer values, make sense.
Unfortunately, it's not what the standard does. For example, the
description of malloc() says:

The malloc function returns either a null pointer or a pointer to
the allocated space.

So I'm afraid we're stuck with the ambiguity.


But you and I can still use the terms correctly if we will.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Jan 21 '06 #16

P: n/a
Joe Wright <jo********@comcast.net> writes:
Keith Thompson wrote:

[snip]
Sure, using the unqualified word "pointer" only to refer to pointer
objects and using "address" to refer to pointer values, make sense.
Unfortunately, it's not what the standard does. For example, the
description of malloc() says:
The malloc function returns either a null pointer or a pointer to
the allocated space.
So I'm afraid we're stuck with the ambiguity.


But you and I can still use the terms correctly if we will.


Sure, if there were any agreement on what "correctly" means.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jan 22 '06 #17

P: n/a

"Keith Thompson" <ks***@mib.org> wrote

But you and I can still use the terms correctly if we will.


Sure, if there were any agreement on what "correctly" means.

If a non-C programmer asks "what is a pointer?" the correct answer is "a
variable which holds an address".

However it is unidiomatic to use the term "address" in a C context.
Jan 22 '06 #18

P: n/a
"Malcolm" <re*******@btinternet.com> writes:
"Keith Thompson" <ks***@mib.org> wrote
But you and I can still use the terms correctly if we will.
Sure, if there were any agreement on what "correctly" means.

If a non-C programmer asks "what is a pointer?" the correct answer is "a
variable which holds an address".


Is it? I suppose it depends on which language the programmer is
familiar with.
However it is unidiomatic to use the term "address" in a C context.


C uses the term "address" all over the place; see the unary "&"
operator, for example.

If you consistently use "pointer" to refer to pointer objects, and
"address" to refer to values, your terminology will be entirely
consistent with the C standard -- but the language used in the C
standard won't be entirely consistent with yours.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jan 22 '06 #19

This discussion thread is closed

Replies have been disabled for this discussion.