By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,907 Members | 1,283 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,907 IT Pros & Developers. It's quick & easy.

This pointer question!

P: n/a
Guys,

As you know static member functions do not have a this pointer. so
instead, what shall i do?

for example ... consider I want to call

Code: ( text )

1.
pthread_create(&thID,NULL,classA::B, (void *) this);

and it is called in an static method so instead of this what can I
put??

Thanks,

Amir.

May 28 '07 #1
Share this Question
Share on Google+
8 Replies


P: n/a
am***@parsonline.net wrote:
Guys,

As you know static member functions do not have a this pointer. so
instead, what shall i do?

for example ... consider I want to call

Code: ( text )

1.
pthread_create(&thID,NULL,classA::B, (void *) this);
An off topic but common question. You must pass an extern "C" linkage
function to C library functions that expect a function pointer as one of
their parameters.

You *must* not pass a class member function and *should* not pass a
static member function.

--
Ian Collins.
May 28 '07 #2

P: n/a
Ian Collins a écrit :
am***@parsonline.net wrote:
>Guys,

As you know static member functions do not have a this pointer. so
instead, what shall i do?

for example ... consider I want to call

Code: ( text )

1.
pthread_create(&thID,NULL,classA::B, (void *) this);
An off topic but common question. You must pass an extern "C" linkage
function to C library functions that expect a function pointer as one of
their parameters.

You *must* not pass a class member function and *should* not pass a
static member function.
I didn't know about the static member function. Why is that (some
portability issue on their representation I presume)?

You can use template along the following pattern (using intermediary
class or not, using richer templatization ...):

//! execute member function
template<class T>
void* pthread_class_threadifier(void* param)
{
//better to add try/catch otherwise, stack unwinding doesn't happen
in some cases
std::auto_ptr<std::pair<T*,void(T::*)() p(
reinterpret_cast<std::pair<T*,void(T::*)()>*>(para m));

((p->first)->*(p->second))();

return NULL;
}

//! start thread on given method of given class
template<class T>
int pthread_create_class(pthread_t& thID, T& object, void (T::*method)())
{
std::pair<T*,void (T::*)()>* param=
new std::pair<T*,void (T::*)()>(&object,method);

int ret= pthread_create(&thID,NULL,
pthread_class_threadifier<T>,
reinterpret_cast<void*>(param));

if(ret)delete param;

return ret;
}

And then:
//test class
class A
{
public:
//this method will be threadified
void a()
{
std::cout<<"OK"<<std::endl;
}
};

int main()
{

A a1;
pthread_t pid;

//create thread
int ret=pthread_create_class(pid,a1,&A::a);
if (ret)
{
std::cerr<<"Error: "<<ret<<std::endl;
}

//wait a bit
::sleep(1);

return 0;
}

Michael
May 28 '07 #3

P: n/a
Michael DOUBEZ wrote:
Ian Collins a écrit :
>am***@parsonline.net wrote:
>>Guys,

As you know static member functions do not have a this pointer. so
instead, what shall i do?

for example ... consider I want to call

Code: ( text )

1.
pthread_create(&thID,NULL,classA::B, (void *) this);
An off topic but common question. You must pass an extern "C" linkage
function to C library functions that expect a function pointer as one of
their parameters.

You *must* not pass a class member function and *should* not pass a
static member function.

I didn't know about the static member function. Why is that (some
portability issue on their representation I presume)?
There is no guarantee that any C++ function will have the same linkage
as a C function. In practice most non-member functions do, but the
compiler is free to issue a diagnostic when one is passed to a function
expecting an extern "C" function pointer.
You can use template along the following pattern (using intermediary
class or not, using richer templatization ...):
This isn't strictly correct (but it will probably work) as function
templates can not have extern "C" linkage.

--
Ian Collins.
May 28 '07 #4

P: n/a
On May 28, 9:42 pm, Ian Collins <ian-n...@hotmail.comwrote:
Michael DOUBEZ wrote:
Ian Collins a écrit :
a...@parsonline.net wrote:
>As you know static member functions do not have a this pointer. so
instead, what shall i do?
>for example ... consider I want to call
>Code: ( text )
> 1.
pthread_create(&thID,NULL,classA::B, (void *) this);
An off topic but common question. You must pass an extern "C" linkage
function to C library functions that expect a function pointer as one of
their parameters.
You *must* not pass a class member function and *should* not pass a
static member function.
I didn't know about the static member function. Why is that (some
portability issue on their representation I presume)?
There is no guarantee that any C++ function will have the same linkage
as a C function. In practice most non-member functions do, but the
compiler is free to issue a diagnostic when one is passed to a function
expecting an extern "C" function pointer.
Not "free to", required to. Linkage is part of type, and
passing a function with "C++" linkage to pthread_create is just
as much an error as passing one which takes an int instead of a
pointer, or which returns void, instead of void*.

With regards to Michael's code, I don't think a template
instantiation can have C linkage, so the code is illegal.
You can use template along the following pattern (using intermediary
class or not, using richer templatization ...):
This isn't strictly correct (but it will probably work) as function
templates can not have extern "C" linkage.
In which case, a good compiler, in strictly conforming mode,
should refuse to compile the code. (Note that both g++ and VC++
get this wrong.)

--
James Kanze (GABI Software) email:ja*********@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

May 29 '07 #5

P: n/a
James Kanze wrote:
On May 28, 9:42 pm, Ian Collins <ian-n...@hotmail.comwrote:
>Michael DOUBEZ wrote:
>>I didn't know about the static member function. Why is that (some
portability issue on their representation I presume)?
>There is no guarantee that any C++ function will have the same linkage
as a C function. In practice most non-member functions do, but the
compiler is free to issue a diagnostic when one is passed to a function
expecting an extern "C" function pointer.

Not "free to", required to. Linkage is part of type, and
passing a function with "C++" linkage to pthread_create is just
as much an error as passing one which takes an int instead of a
pointer, or which returns void, instead of void*.
Agreed, but many (most?) don't. Sun CC is the only compiler I know that
does object.

--
Ian Collins.
May 29 '07 #6

P: n/a
On Tue, 29 May 2007 20:22:31 +1200, Ian Collins wrote:
>James Kanze wrote:
>Not "free to", required to. Linkage is part of type, and
passing a function with "C++" linkage to pthread_create is just
as much an error as passing one which takes an int instead of a
pointer, or which returns void, instead of void*.
Agreed, but many (most?) don't. Sun CC is the only compiler I know that
does object.
Of course the EDG front-end in strict mode rejects it as well, though
not all EDG-based compilers do. The front-end offers the
--implicit_extern_c_type_conversion and
--no_implicit_extern_c_type_conversion options to control this, but it
is up to the compiler writer whether they are made available to the
user (of course, the conversion cannot work if the compiler uses
incompatible calling conventions for C and C++ functions).

--
Gennaro Prota -- C++ Developer, For Hire
https://sourceforge.net/projects/breeze/
(replace 'address' with 'name.surname' to mail)
May 30 '07 #7

P: n/a
On May 28, 4:07 pm, a...@parsonline.net wrote:
Guys,

As you know static member functions do not have a this pointer. so
instead, what shall i do?

for example ... consider I want to call

Code: ( text )

1.
pthread_create(&thID,NULL,classA::B, (void *) this);

and it is called in an static method so instead of this what can I
put??
If you can you're much better off using Boost::threads for this. The
following is off the top of my head:

#include <boost/bind.hpp>
#include <boost/thread/thread.hpp>

class A {
public:
void a() { std::cout << "The A" << std::endl; }
} anA;

int main() {
boost::thread theThread( boost::bind( &A::a, anA ) );
theThread.join();
return 0;
}

Your example would look like more like this:

boost::thread t( boost::bind( &classA::B, this ) );
// Do something else
t.join(); // Wait for this->B() to finish
K

May 30 '07 #8

P: n/a
On May 30, 4:41 pm, Kirit Sælensminde <kirit.saelensmi...@gmail.com>
wrote:
On May 28, 4:07 pm, a...@parsonline.net wrote:
As you know static member functions do not have a this pointer. so
instead, what shall i do?
for example ... consider I want to call
Code: ( text )
1.
pthread_create(&thID,NULL,classA::B, (void *) this);
and it is called in an static method so instead of this what can I
put??
If you can you're much better off using Boost::threads for this.
It depends. The conception of Boost::threads is far from
perfect, and it's all to easy to accidentally get a detached
thread due to an unexpected exception. The advantages of
Boost::threads limit themselves to: 1) they've already wrapped
the system API, so you don't have to learn both Windows and
Posix, and worry about system dependant code yourself, and 2) in
cases where you want to view the new thread as a functional
object, with its own totally independant lifetime,
Boost::threads has already handled the copying and the
synchronization issues at thread start up for you. (2 is almost
always the case for detached threads, rarely however for
joinable threads.)

--
James Kanze (GABI Software) email:ja*********@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

May 31 '07 #9

This discussion thread is closed

Replies have been disabled for this discussion.