Use of & operator for function pointers

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

Hi,

I was curious whether or not to use the & operator when creating a
function pointer. It seems, that both &func and plain func create a
pointer of the appropriate function pointer type.

However, for member function pointers it seems that the use of & is
mandatory, the following code compiles but does not when uncommenting
the initialization of c:

class A
{
public:
static void foo();
void bar();
};

void A::foo()
{}

void A::bar()
{}

int main()
{
typedef void (*func)();
func a(A::foo);
func b(&A::foo);

typedef void (A::*memfunc)();
//memfunc c(A::bar);
memfunc d(&A::bar);

return 0;
}

Is there a rationale behind this "inconsistency"? What would you
recommend as the correct way to retrieve a pointer of an static
function, with or without &?

I believe that this is due to some C-ism that has survived, since
there's nothing else you can mean when you write a statement like

func a = A::foo

they made the & optional. I however always uses & since it makes the
intent clear.

 

[Neelesh Bodas]

Hi,

I was curious whether or not to use the & operator when creating a
function pointer. It seems, that both &func and plain func create a
pointer of the appropriate function pointer type.

However, for member function pointers it seems that the use of & is
mandatory, the following code compiles but does not when uncommenting
the initialization of c:

class A
{
public:
static void foo();
void bar();

};

void A::foo()
{}

void A::bar()
{}

int main()
{
typedef void (*func)();
func a(A::foo);
func b(&A::foo);

typedef void (A::*memfunc)();
//memfunc c(A::bar);
memfunc d(&A::bar);

return 0;

}

Is there a rationale behind this "inconsistency"? What would you
recommend as the correct way to retrieve a pointer of an static
function, with or without &?

Yours,
Daniel

The "function name" gets converted to the function pointer using
"implicit conversions. Thus, the following two give same result but
are not the same:

void foo();

typedef void (*fptr)();

fptr f1 = foo; //uses trivial conversion function name to function
pointer
fptr f2 = &foo; // no conversion, expression on the right-side is
already a pointer

In most of the cases, a function name gets implicitly converted into a
function pointer, and hence it doesnot matter what you write.
However, there are cases where it does matter:

int main()
{
sizeof(foo); //Error, sizeof cannot be applied to a function, and
sizeof doesnot allow function-name-to-pointer conversion on its
argument
sizeof(&foo); //fine, sizeof can be applied to a pointer
}

-N

 

[Daniel Kraft]

Hi,

I was curious whether or not to use the & operator when creating a
function pointer. It seems, that both &func and plain func create a
pointer of the appropriate function pointer type.

However, for member function pointers it seems that the use of & is
mandatory, the following code compiles but does not when uncommenting
the initialization of c:

class A
{
public:
static void foo();
void bar();
};

void A::foo()
{}

void A::bar()
{}

int main()
{
typedef void (*func)();
func a(A::foo);
func b(&A::foo);

typedef void (A::*memfunc)();
//memfunc c(A::bar);
memfunc d(&A::bar);

return 0;
}

Is there a rationale behind this "inconsistency"? What would you
recommend as the correct way to retrieve a pointer of an static
function, with or without &?

Yours,
Daniel

 

[Daniel Kraft]

I believe that this is due to some C-ism that has survived, since
there's nothing else you can mean when you write a statement like

func a = A::foo

they made the & optional. I however always uses & since it makes the
intent clear.

Yes, that is what I thought of and used to use &; however, later I
thought of that A::foo is some kind of "functor" as you can call it like
A::foo() as the function-pointer is and therefore "A::foo" *is* a
function pointer rather than something to obtain the address from...

Well, sounds weird, I know However, this made me believe without & is
the more "correct" way... But as I found for member functions this
works only with &, I got suspicious... I think in the future I will
come back to & again.

Thank you!
Daniel