static member functions vs. member function pointers

[paul]

Hi,
I have seen the use of static member functions for callbacks by
passing the name of the static member function and the this pointer to
the code that will call back.
I was thinking the same can be achieved by using member function
pointers and the this pointer.

E.g.
void FuncThatWillCallback( MyClass::staticFunc, (void *)this)
{
staticFunc(this);
}
void FuncThatWillCallback( PtrToMemberFunc, (void *)this)
{
this->PtrToMemberFunc;
}

Is there a reason why the static member function trick is so widely
used? (Except when FuncThatWillCallback is part of a 3rd party lib).

 

[Alf P. Steinbach]

* paul:

Hi,
I have seen the use of static member functions for callbacks by
passing the name of the static member function and the this pointer to
the code that will call back.
I was thinking the same can be achieved by using member function
pointers and the this pointer.

E.g.
void FuncThatWillCallback( MyClass::staticFunc, (void *)this)
{
staticFunc(this);
}
void FuncThatWillCallback( PtrToMemberFunc, (void *)this)
{
this->PtrToMemberFunc;
}

Have you tried compiling any of the above?

Is there a reason why the static member function trick is so widely
used? (Except when FuncThatWillCallback is part of a 3rd party lib).

Do you have any data that supports your contention that static member functions
are widely used for callbacks in code that doesn't involve 3rd party libraries?


Cheers, & hope these question help,

- Alf

 

[Vladimir Jovic]

Best to post real code

Hi,
I have seen the use of static member functions for callbacks by
passing the name of the static member function and the this pointer to
the code that will call back.
I was thinking the same can be achieved by using member function
pointers and the this pointer.

You don't need this pointer, but you have to pass the object of the
class type for which you want to create a callback to a member function.

E.g.
void FuncThatWillCallback( MyClass::staticFunc, (void *)this)
{
staticFunc(this);
}
void FuncThatWillCallback( PtrToMemberFunc, (void *)this)
{
this->PtrToMemberFunc;
}

This doesn't look like a legal c++. You didn't pass parameters when you
called the member function. And, can you call the member function on a
void pointer?

Is there a reason why the static member function trick is so widely
used? (Except when FuncThatWillCallback is part of a 3rd party lib).

"Widely used" is so vague term.

 

[DerTopper]

I have seen the use of static member functions for callbacks by
passing the name of the static member function and the this pointer to
the code that will call back.
I was thinking the same can be achieved by using member function
pointers and the this pointer.
E.g.
void FuncThatWillCallback( MyClass::staticFunc, (void *)this)
{
staticFunc(this);
}
void FuncThatWillCallback( PtrToMemberFunc, (void *)this)
{
this->PtrToMemberFunc;
}

Is there a reason why the static member function trick is so widely
used? (Except when FuncThatWillCallback is part of a 3rd party lib).

Most probably we are talking about APIs that are actually C APIs, like
the most of MS's Windows API. There you can create threads by passing
a pointer to a C function to the CreateThread function. If you want to
use some object to service the thread, you usually pass the 'this'
pointer to the thread function.

Note that this API is designed for C, so that it doesn't know how to
handle member pointers.

Of course, if you want to define our own callback mechanism, you
should rather make it interface based:
class ICallableObject
{
public:
virtual void DoSomething (/* some args*/) = 0;
};

void FuncThatWillCallback (ICallableObject* pCallableObject)
{
pCallableObject->DoSomething (/* args */);
}

This is much cleaner that the C version, but can only be used under C+
+.

Regards,
Stuart

 

[James Kanze]

I have seen the use of static member functions for callbacks
by passing the name of the static member function and the this
pointer to the code that will call back.

That's interesting. I've never seen it, at least not in correct
code.

I was thinking the same can be achieved by using member
function pointers and the this pointer.

E.g.
void FuncThatWillCallback( MyClass::staticFunc, (void *)this)
{
staticFunc(this);}

void FuncThatWillCallback( PtrToMemberFunc, (void *)this)
{
this->PtrToMemberFunc;
}

Is there a reason why the static member function trick is so
widely used? (Except when FuncThatWillCallback is part of a
3rd party lib).

As I said, I've never seen it used in correct code, period. In
pure C++, there are two widespread solutions: a callback
interface, using virtual functions, from which the client code
derives, and functional objects passed to a template. About the
only time I've seen anything else has been when interfacing to
legacy API's, in C, and in such cases, you can't pass a static
member function either, because the callback function must have
"C" linkage.

 

[paul]

* paul:







Have you tried compiling any of the above?

No I didn't compile it and you're right the syntax is wrong. I just
wanted to get an opinion on the differences between the two.

Do you have any data that supports your contention that static member functions
are widely used for callbacks in code that doesn't involve 3rd party libraries?

I have seen it a lot in the code I have worked on.

Paul

 

[Alf P. Steinbach]

* James Kanze:

As I said, I've never seen it used in correct code, period. In
pure C++, there are two widespread solutions: a callback
interface, using virtual functions, from which the client code
derives, and functional objects passed to a template. About the
only time I've seen anything else has been when interfacing to
legacy API's, in C, and in such cases, you can't pass a static
member function either, because the callback function must have
"C" linkage.

Well you can. Just not with standard's blessing. I think it would be difficult
to find a compiler that with the proper option (usually default) doesn't support it.


Cheers,

- Alf

 

[James Kanze]

* James Kanze:

Well you can. Just not with standard's blessing. I think it
would be difficult to find a compiler that with the proper
option (usually default) doesn't support it.

Sun CC generates a diagnostic, and as far as I know, you can't
turn the diagnostic off. And I've used C++ compilers where it
simply didn't work; the reason the standard doesn't allow it is
because there are cases where it won't work.

Note that Windows, or at least VC++, is a bit special here,
because the compiler doesn't use the standard mechanism for
linkage specification. Rather, it separates linkage into two
separate parts: name mangling (specified by ``extern "..."'')
and calling conventions (specified by Microsoft extensions, e.g.
__cdecl, __stdcall, __fastcall, etc.). These extensions do
apply to static member functions. Also, the compiler does
require that a pointer to a function and the function have the
same calling conventions. And the system functions, at least,
requre different calling conventions than the default, so you
have to use Microsoft's extensions if you're going to use a
function as a callback for Windows.

 

[Alf P. Steinbach]

* James Kanze:

Sun CC generates a diagnostic, and as far as I know, you can't
turn the diagnostic off.

Have you tried

-erroff=badargtype2w

?

And I've used C++ compilers where it
simply didn't work;

Well I still think it would be difficult to find such a compiler!

the reason the standard doesn't allow it is
because there are cases where it won't work.

Yes. But aren't those are the cases where you (or someone else) have chosen for
C++ and C to have different calling conventions?

Note that Windows, or at least VC++, is a bit special here,
because the compiler doesn't use the standard mechanism for
linkage specification. Rather, it separates linkage into two
separate parts: name mangling (specified by ``extern "..."'')
and calling conventions (specified by Microsoft extensions, e.g.
__cdecl, __stdcall, __fastcall, etc.). These extensions do
apply to static member functions. Also, the compiler does
require that a pointer to a function and the function have the
same calling conventions. And the system functions, at least,
requre different calling conventions than the default, so you
have to use Microsoft's extensions if you're going to use a
function as a callback for Windows.

Yes. I've always thought that both the standard's approach and Microsoft's
approach are horrible, in this regard. It would be nice to be able to specify
such things via C++0x attribute notation.


Cheers,

- Alf