Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > How to solve the error without using static keyword

Reply
Thread Tools

How to solve the error without using static keyword

 
 
iceman
Guest
Posts: n/a
 
      02-13-2008
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:rint_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
 
Reply With Quote
 
 
 
 
Daniel T.
Guest
Posts: n/a
 
      02-13-2008
iceman <(E-Mail Removed)> 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:rint_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)
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      02-13-2008
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:rint_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.
 
Reply With Quote
 
iceman
Guest
Posts: n/a
 
      02-13-2008
I am confused so how should I go about this?

 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      02-13-2008
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.
 
Reply With Quote
 
kasthurirangan.balaji@gmail.com
Guest
Posts: n/a
 
      02-13-2008
On Feb 13, 9:20*am, iceman <(E-Mail Removed)> 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.
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      02-13-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> On Feb 13, 9:20 am, iceman <(E-Mail Removed)> 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.
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      02-13-2008
On Feb 13, 6:54 am, Ian Collins <(E-Mail Removed)> wrote:
> (E-Mail Removed) wrote:
> > On Feb 13, 9:20 am, iceman <(E-Mail Removed)> 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:(E-Mail Removed)
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
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      02-13-2008
James Kanze wrote:
> On Feb 13, 6:54 am, Ian Collins <(E-Mail Removed)> 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.
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      02-14-2008
On Feb 13, 10:22 am, Ian Collins <(E-Mail Removed)> wrote:
> James Kanze wrote:
> > On Feb 13, 6:54 am, Ian Collins <(E-Mail Removed)> 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:(E-Mail Removed)
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
put static keyword inside the JSP scripplets error Matt Java 3 03-15-2012 10:10 AM
How to solve the error without using static keyword iceman C++ 0 02-13-2008 02:05 AM
RE: keyword checker - keyword.kwlist Hamilton, William Python 4 05-13-2007 06:31 AM
keyword checker - keyword.kwlist tom@finland.com Python 6 05-10-2007 04:53 PM



Advertisments