How to solve the error without using static keyword

Discussion in 'C++' started by iceman, Feb 13, 2008.

  1. iceman

    iceman Guest

    Hi all,
    I am trying to create a thread in one of the methods of the class but
    this errors keeps throwing up
    I create the thread with
    pthread_create (&thread_id, NULL, &print_xs, NULL);

    Then I get the error
    AppClass.cpp:78: error: ISO C++ forbids taking the address of an
    unqualified or bracketed non-static member function to form a pointer
    to member function. Say '&AppClass::print_xs'
    AppClass.cpp:78: error: cannot convert 'void* (AppClass::*)(void*)' to
    'void* (*)(void*)' for argument '3' to 'int pthread_create(pthread_t*,
    const pthread_attr_t*, void* (*)(void*), void*)'


    But is I say
    pthread_create (&thread_id, NULL, &print_xs, NULL);
    I get the error

    AppClass.cpp:78: error: cannot convert 'void* (AppClass::*)(void*)' to
    'void* (*)(void*)' for argument '3' to 'int pthread_create(pthread_t*,
    const pthread_attr_t*, void* (*)(void*), void*)'

    How can I solve this without making print_xs static?
    Cheers
    iceman, Feb 13, 2008
    #1
    1. Advertising

  2. iceman

    Daniel T. Guest

    iceman <> wrote:

    > I am trying to create a thread in one of the methods of the class but
    > this errors keeps throwing up
    > I create the thread with
    > pthread_create (&thread_id, NULL, &print_xs, NULL);
    >
    > Then I get the error
    > AppClass.cpp:78: error: ISO C++ forbids taking the address of an
    > unqualified or bracketed non-static member function to form a pointer
    > to member function. Say '&AppClass::print_xs'
    > AppClass.cpp:78: error: cannot convert 'void* (AppClass::*)(void*)' to
    > 'void* (*)(void*)' for argument '3' to 'int pthread_create(pthread_t*,
    > const pthread_attr_t*, void* (*)(void*), void*)'
    >
    >
    > But is I say
    > pthread_create (&thread_id, NULL, &print_xs, NULL);
    > I get the error
    >
    > AppClass.cpp:78: error: cannot convert 'void* (AppClass::*)(void*)' to
    > 'void* (*)(void*)' for argument '3' to 'int pthread_create(pthread_t*,
    > const pthread_attr_t*, void* (*)(void*), void*)'
    >
    > How can I solve this without making print_xs static?


    You make a static function that calls print_xs() on the appropriate
    member, then pass that function to pthread_create.

    Better yet, use Boost::thread.
    (http://www.boost.org/doc/html/thread.html)
    Daniel T., Feb 13, 2008
    #2
    1. Advertising

  3. iceman

    Ian Collins Guest

    iceman wrote:
    > Hi all,
    > I am trying to create a thread in one of the methods of the class but
    > this errors keeps throwing up
    > I create the thread with
    > pthread_create (&thread_id, NULL, &print_xs, NULL);
    >
    > Then I get the error
    > AppClass.cpp:78: error: ISO C++ forbids taking the address of an
    > unqualified or bracketed non-static member function to form a pointer
    > to member function. Say '&AppClass::print_xs'
    > AppClass.cpp:78: error: cannot convert 'void* (AppClass::*)(void*)' to
    > 'void* (*)(void*)' for argument '3' to 'int pthread_create(pthread_t*,
    > const pthread_attr_t*, void* (*)(void*), void*)'
    >
    >
    > But is I say
    > pthread_create (&thread_id, NULL, &print_xs, NULL);
    > I get the error
    >
    > AppClass.cpp:78: error: cannot convert 'void* (AppClass::*)(void*)' to
    > 'void* (*)(void*)' for argument '3' to 'int pthread_create(pthread_t*,
    > const pthread_attr_t*, void* (*)(void*), void*)'
    >
    > How can I solve this without making print_xs static?
    > Cheers


    That won't solve your problem either. You can only pass an extern "C"
    free function to a C library function.

    --
    Ian Collins.
    Ian Collins, Feb 13, 2008
    #3
  4. iceman

    iceman Guest

    I am confused so how should I go about this? :(
    iceman, Feb 13, 2008
    #4
  5. iceman

    Ian Collins Guest

    iceman wrote:
    > I am confused so how should I go about this? :(
    >

    Go about what?

    If you are confused about calling a class method as a thread function,
    you can look back though the numerous thread about this here and on c.p.t.

    Or just pass an extern "C" free function, like

    extern "C" void* runIt( void* p ) {
    return static_cast<YourClass*>(p)->run();
    }

    --
    Ian Collins.
    Ian Collins, Feb 13, 2008
    #5
  6. iceman

    Guest

    On Feb 13, 9:20 am, iceman <> wrote:
    > I am confused so how should I go about this? :(


    The choice is absolutely yours.

    1)Learn boost::threads and use it(as suggested by Daniel).

    2)If you want to stick with pthreads alone, pass free
    functions(doesn't need to be an extern 'C', c++ also supports free
    functions) rather than member functions to pthread lib calls. Wherever
    required, you can make the free functions friend of the class. Better
    way of packaging is to have the free functions stick along with the
    class declaration in the same header file(design decisions need to
    considered).

    Thanks,
    Balaji.
    , Feb 13, 2008
    #6
  7. iceman

    Ian Collins Guest

    wrote:
    > On Feb 13, 9:20 am, iceman <> wrote:
    >> I am confused so how should I go about this? :(

    >
    > The choice is absolutely yours.
    >
    > 1)Learn boost::threads and use it(as suggested by Daniel).
    >
    > 2)If you want to stick with pthreads alone, pass free
    > functions(doesn't need to be an extern 'C', c++ also supports free
    > functions)


    Sorry, but is does C++ functions have C++ linkage, extern "C" functions
    have C linkage. A C++ free function may work, but then again, it may not.

    I say again (I'm sure not for the last time) the only correct type of
    function to pass to a C library is an extern "C" linkage function.

    --
    Ian Collins.
    Ian Collins, Feb 13, 2008
    #7
  8. iceman

    James Kanze Guest

    On Feb 13, 6:54 am, Ian Collins <> wrote:
    > wrote:
    > > On Feb 13, 9:20 am, iceman <> wrote:
    > >> I am confused so how should I go about this? :(


    > > The choice is absolutely yours.


    > > 1)Learn boost::threads and use it(as suggested by Daniel).


    > > 2)If you want to stick with pthreads alone, pass free
    > > functions(doesn't need to be an extern 'C', c++ also supports free
    > > functions)


    > Sorry, but is does C++ functions have C++ linkage, extern "C"
    > functions have C linkage. A C++ free function may work, but
    > then again, it may not.


    It won't work if you have a standard conformant compiler. If
    you're compiling in standard conformant mode, and the compiler
    doesn't issue a diagnostic, it's an error in the compiler.

    (I would imagine that it's a fairly widespread extension to
    support it in non standard conformant mode, but it remains an
    extension.)

    > I say again (I'm sure not for the last time) the only correct
    > type of function to pass to a C library is an extern "C"
    > linkage function.


    You won't stop saying it until compilers start implementing the
    standard. (One sometimes gets the impression that compilers
    treat the standard as a sort of a supermarket---picking and
    choosing what they like in it---, and not as part of a contract
    with the user.)

    --
    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, Feb 13, 2008
    #8
  9. iceman

    Ian Collins Guest

    James Kanze wrote:
    > On Feb 13, 6:54 am, Ian Collins <> wrote:
    >
    >> I say again (I'm sure not for the last time) the only correct
    >> type of function to pass to a C library is an extern "C"
    >> linkage function.

    >
    > You won't stop saying it until compilers start implementing the
    > standard.
    >

    At least my day-to-day compiler (Sun CC) does in this instance!

    --
    Ian Collins.
    Ian Collins, Feb 13, 2008
    #9
  10. iceman

    James Kanze Guest

    On Feb 13, 10:22 am, Ian Collins <> wrote:
    > James Kanze wrote:
    > > On Feb 13, 6:54 am, Ian Collins <> wrote:


    > >> I say again (I'm sure not for the last time) the only correct
    > >> type of function to pass to a C library is an extern "C"
    > >> linkage function.


    > > You won't stop saying it until compilers start implementing the
    > > standard.


    > At least my day-to-day compiler (Sun CC) does in this instance!


    Mine used to:). (We've gradually been migrating from
    Solaris/Sun CC to Linux/g++, and g++ is broken in this regard.)

    More to the point, I've actually used a compiler where C and C++
    had different calling conventions. Which meant that if you
    tricked the compiler into accepting the code (e.g. by means of a
    reinterpret_cast), it wouldn't work at runtime.

    As I've said elsewhere, there are very good reasons why the
    standards committee make the linkage part of the type. (It
    wasn't in CFront.) I'm not sure that they're still relevant,
    but IMHO, it makes sense that the linkage be part of the
    type---I certainly wouldn't expect `extern "Fortran"' or `extern
    "Ada"' to use C++ compatible calling conventions, and if `extern
    "AnythingElseButC"' must be part of the type, then a special
    rule for C seems just that, a special rule (aka a hack).

    --
    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, Feb 14, 2008
    #10
    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. Matt
    Replies:
    3
    Views:
    1,109
    aatishp
    Mar 15, 2012
  2. Replies:
    6
    Views:
    449
    Peter Otten
    May 10, 2007
  3. Hamilton, William

    RE: keyword checker - keyword.kwlist

    Hamilton, William, May 10, 2007, in forum: Python
    Replies:
    4
    Views:
    349
  4. iceman
    Replies:
    0
    Views:
    303
    iceman
    Feb 13, 2008
  5. bruce
    Replies:
    0
    Views:
    489
    bruce
    Jul 21, 2008
Loading...

Share This Page