Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C++ (http://www.velocityreviews.com/forums/f39-c.html)
-   -   static member functions vs. member function pointers (http://www.velocityreviews.com/forums/t681895-static-member-functions-vs-member-function-pointers.html)

paul 04-29-2009 06:41 AM

static member functions vs. member function pointers
 
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 04-29-2009 06:50 AM

Re: 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;
> }


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

--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!

Vladimir Jovic 04-29-2009 06:57 AM

Re: static member functions vs. member function pointers
 
Best to post real code

paul wrote:
> 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@web.de 04-29-2009 07:56 AM

Re: static member functions vs. member function pointers
 
paul wrote:
> 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 04-29-2009 09:55 AM

Re: static member functions vs. member function pointers
 
On Apr 29, 8:41 am, paul <pradhan.push...@gmail.com> wrote:

> 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.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34



paul 04-29-2009 04:36 PM

Re: static member functions vs. member function pointers
 
On Apr 28, 11:50*pm, "Alf P. Steinbach" <al...@start.no> wrote:
> * 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?

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.

> > 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?

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

Paul

Alf P. Steinbach 04-30-2009 02:07 AM

Re: static member functions vs. member function pointers
 
* 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

--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!

James Kanze 04-30-2009 10:06 AM

Re: static member functions vs. member function pointers
 
On Apr 30, 4:07 am, "Alf P. Steinbach" <al...@start.no> wrote:
> * 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.


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.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Alf P. Steinbach 04-30-2009 11:03 AM

Re: static member functions vs. member function pointers
 
* James Kanze:
> On Apr 30, 4:07 am, "Alf P. Steinbach" <al...@start.no> wrote:
>> * 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.

>
> 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

--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!


All times are GMT. The time now is 06:05 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.