static member functions vs. member function pointers

Discussion in 'C++' started by paul, Apr 29, 2009.

  1. paul

    paul Guest

    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).
    paul, Apr 29, 2009
    #1
    1. Advertising

  2. * 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!
    Alf P. Steinbach, Apr 29, 2009
    #2
    1. Advertising

  3. 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.
    Vladimir Jovic, Apr 29, 2009
    #3
  4. paul

    Guest

    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
    , Apr 29, 2009
    #4
  5. paul

    James Kanze Guest

    On Apr 29, 8:41 am, 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.


    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:
    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
    James Kanze, Apr 29, 2009
    #5
  6. paul

    paul Guest

    On Apr 28, 11:50 pm, "Alf P. Steinbach" <> 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
    paul, Apr 29, 2009
    #6
  7. * 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!
    Alf P. Steinbach, Apr 30, 2009
    #7
  8. paul

    James Kanze Guest

    On Apr 30, 4:07 am, "Alf P. Steinbach" <> 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:
    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
    James Kanze, Apr 30, 2009
    #8
  9. * James Kanze:
    > On Apr 30, 4:07 am, "Alf P. Steinbach" <> 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!
    Alf P. Steinbach, Apr 30, 2009
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    2
    Views:
    444
  2. John Doe
    Replies:
    9
    Views:
    349
    lilburne
    Oct 23, 2003
  3. 0to60
    Replies:
    4
    Views:
    514
    jeffc
    Nov 21, 2003
  4. dolphin
    Replies:
    3
    Views:
    1,342
    Pete Becker
    Dec 5, 2007
  5. Hamish
    Replies:
    3
    Views:
    575
    Alf P. Steinbach
    Jan 25, 2008
Loading...

Share This Page