How to solve the error without using static keyword

I

iceman

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
 
D

Daniel T.

iceman said:
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)
 
I

Ian Collins

iceman said:
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.
 
I

Ian Collins

iceman said:
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();
}
 
K

kasthurirangan.balaji

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

Ian Collins

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

James Kanze

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

James Kanze

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

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top