Creating thread in C++

[mthread]

Hi,
I am trying to create a thread by doing some thing like this.


class myclass
{
private :
.....
public :
void* My_function(void* voidPtr);
}


int main()
{
pthread_t tId;
myclass obj;
pthread_create(&tId, NULL, obj.My_function, NULL);
}


I get compilation error when i do this. I have a good experience in
multithreaded programming using C. But this is the first time I am
trying to do it in C++. I might be naive. I would like to know how I
can create a thread in C++(using C posix threads).

 

[Kira Yamato]

Hi,
I am trying to create a thread by doing some thing like this.


class myclass
{
private :
.....
public :
void* My_function(void* voidPtr);
}


int main()
{
pthread_t tId;
myclass obj;
pthread_create(&tId, NULL, obj.My_function, NULL);
}


I get compilation error when i do this. I have a good experience in
multithreaded programming using C. But this is the first time I am
trying to do it in C++. I might be naive. I would like to know how I
can create a thread in C++(using C posix threads).

You can't pass a C++ method as if it is a C function to
pthread_create(), which expects a C function.

 

[Dave Rahardja]

I get compilation error when i do this. I have a good experience in
multithreaded programming using C. But this is the first time I am
trying to do it in C++. I might be naive. I would like to know how I
can create a thread in C++(using C posix threads).

C++ doesn't have any concept of threads. Try asking in a group for your
platform instead.

-dr

ps: hint: you need a static member function.

 

[Daniel T.]

Hi,
I am trying to create a thread by doing some thing like this.


class myclass
{
private :
.....
public :
void* My_function(void* voidPtr);
}


int main()
{
pthread_t tId;
myclass obj;
pthread_create(&tId, NULL, obj.My_function, NULL);
}


I get compilation error when i do this. I have a good experience in
multithreaded programming using C. But this is the first time I am
trying to do it in C++. I might be naive. I would like to know how I
can create a thread in C++(using C posix threads).

obj.My_function is not a function pointer.

The best way to write multi-threaded applications with C++ is to use
Boost threads. (http://www.boost.org/doc/html/thread.html)

 

[AnonMail2005]

Hi,
  I am trying to create a thread by doing some thing like this.

class  myclass
{
  private :
         .....
   public :
           void* My_function(void* voidPtr);

}

int main()
{
pthread_t tId;
myclass obj;
pthread_create(&tId, NULL, obj.My_function, NULL);

}

I get compilation error when i do this. I have  a good experience in
multithreaded programming using C. But this is the first time I am
trying to do it in C++. I might be naive. I would like to know how I
can create a thread in C++(using C posix threads).

Making your function static or free standing (not part of a class)
should do the trick to make it look like a "C" function.

HTH

 

[Tomás Ó hÉilidhe]

int main()
{
pthread_t tId;
myclass obj;
pthread_create(&tId, NULL, obj.My_function, NULL);
}


I get compilation error when i do this. I have a good experience in
multithreaded programming using C. But this is the first time I am
trying to do it in C++. I might be naive. I would like to know how I
can create a thread in C++(using C posix threads).

The C++ standard doesn't mention anything about threads, however there
are C++ communities built up dedicated to multi-threaded programming.

To achieve portable multi-threaded programming, they produce a "cross-
platform library" which people can use in developing a multi-threaded
application which will can be compiled to run on more than one kind of
computer (e.g. Windows Vs Mac Vs Playstation 3).

There's currently no newsgroup in place for discussing cross-platform
programming in C++, which is why I've proposed the creation of
comp.lang.c++.cross-platform. Voting should start in the next day or two
(there's a load of red tape crap at the minute).

I'd appreciate if you'd vote.

 

[James Kanze]

On 2007-12-26 08:11:12 -0600, mthread <[email protected]> said:

C++ doesn't have any concept of threads.

Bullshit. The C++ standard doesn't mention the word in its last
approved edition (althoug it does in the current draft). But
C++ is more than just the standard---things like usability and
portability are also considerations.

And of course, in this case, the fact that threads are involved
is irrelevant to his problem.

Try asking in a group for your platform instead.

No. It's very definitely a C++ problem, and not a Posix
problem. The answer would be the same under Windows, but of
course, different if he were using C.

ps: hint: you need a static member function.

PS: that's not sufficient. The type of function expected by
pthread_create is a ``extern "C" void* f( void* )'', and a
member function, static or not, can never have this type. He
needs a free function (or a broken compiler---g++ will accept a
static member, even in strictest compatibility).

And for the record, from what I've read in the Windows
documentation, you need a function declared with a language
extension (in this particular case, at least)---the Windows
documentation says that the function must be declared WINAPI.
(I don't know, off hand, whether a static member can be WINAPI
or not. Once we enter the realm of compiler extensions,
anything goes, and you'll have to read the documentation.
Provided you can find it.)

 

[James Kanze]

Making your function static or free standing (not part of a
class) should do the trick to make it look like a "C"
function.

I'm not sure what you mean be "look like a C function". The
function must have the type ``extern "C" void* f( void* )'', and
a member function cannot have that type.

 

[James Kanze]

[...]

There's currently no newsgroup in place for discussing cross-platform
programming in C++,

Why do you keep saying this, when it is manifestedly false, and
you know it. What is the subject matter of this group if it
isn't cross-platform (portable) programming in C++?

Of course, precise discussion of a particular API isn't relevant
here, but general threading issues certainly are, along with
things like how to best encapsulate the platform specific API,
how standard issues (e.g. sequence points, volatile) extend to
or what they mean in in a multi-threaded environment (especially
relevant because the C++ standard committee is discussing it as
well at present), or generally portable libraries like (and
especially) Boost. (Again, discussions of the details of a
particular library are best handled in discussion groups or
mailing lists of that library. Independently of whether they
are on topic here or not, that's where you'll usually get the
best answers.)

And of course, anything which concerns the type system (which
was the real problem in the original posting---which didn't
really have anything to do with threading)

 

[Tomás Ó hÉilidhe]

Why do you keep saying this, when it is manifestedly false, and
you know it. What is the subject matter of this group if it
isn't cross-platform (portable) programming in C++?

Cross-platform programming is distinct from portable programming. Cross-
platform programming is more restrictive, such as assuming the existence
of a keyboard, monitor and mouse.

Of course, precise discussion of a particular API isn't relevant
here, but general threading issues certainly are, along with
things like how to best encapsulate the platform specific API,
how standard issues (e.g. sequence points, volatile) extend to
or what they mean in in a multi-threaded environment (especially
relevant because the C++ standard committee is discussing it as
well at present), or generally portable libraries like (and
especially) Boost. (Again, discussions of the details of a
particular library are best handled in discussion groups or
mailing lists of that library. Independently of whether they
are on topic here or not, that's where you'll usually get the
best answers.)

Yes but talk about the wxWidgets cross-platform GUI library isn't
particularly fitting, especially when people reply that the Standard
doesn't know what a keyboard is.

 

[Erik Wikström]

Cross-platform programming is distinct from portable programming. Cross-
platform programming is more restrictive, such as assuming the existence
of a keyboard, monitor and mouse.

I disagree, there are a lot of portable code/applications out there that
makes assumptions about the machines/environments it will run in. Code
is portable if it has been written with portability (the ability to
compile and run with little or no changes) in mind. It does not imply
that it must be compilable and runnable on every platform with a C++
compiler.

 

[Erik Wikström]

I disagree, there are a lot of portable code/applications out there that
makes assumptions about the machines/environments it will run in. Code
is portable if it has been written with portability (the ability to
compile and run with little or no changes) in mind. It does not imply
that it must be compilable and runnable on every platform with a C++
compiler.

Let me correct that: Code is portable if it has the ability to compile/
run on a different platform with little or no changes. There is no
requirement that the portability was intended.

 

[Tomás Ó hÉilidhe]

Code is portable if it has been written with portability (the ability
to compile and run with little or no changes) in mind. It does not
imply that it must be compilable and runnable on every platform with a
C++ compiler.

I disagree. My own definition of portable is that the code will compile and
function as intended on every conceivable implementation of the C++
Standard.

If you're assuming 8-Bit bytes, then it's not portable.

 

[Erik Wikström]

I disagree. My own definition of portable is that the code will compile and
function as intended on every conceivable implementation of the C++
Standard.

If you're assuming 8-Bit bytes, then it's not portable.

You are, of course, entitled to you opinion, but AFAIK my definition is
the most commonly used. But it is always good to clearly define what is
meant when a word is used, to prevent misunderstandings.

 

[Michael DOUBEZ]

"Tom��������������������������������" a écrit :

Cross-platform programming is distinct from portable programming. Cross-
platform programming is more restrictive, such as assuming the existence
of a keyboard, monitor and mouse.

From what you have told us so far, the main subject would be to dicuss
third party libraries/framework that allow a code to be compiled on more
than one architecture (typically linux,win and mac). This is then not
cross-plateform programing group but a kind of promotional and support
group for library choice making.

Simply creating something like wikimatrix for such libraries would be
far enough.

Yes but talk about the wxWidgets cross-platform GUI library isn't
particularly fitting, especially when people reply that the Standard
doesn't know what a keyboard is.

Talk about the wxWidgets is particularly fitting on their own discussion
system and it helps them design better interface and documentation from
the questions that arise. Another communication channel would just make
more noise.

My understanding of what James Kanze said, and I agree, is that technics
that are used in *making* cross plateform libraries are on-topic here.
But particular library discussions and and problems specifics to an OS
should happen on their respective communication channel.

If you could explain the added value of the group you propose in
realistic relation to current practices, people could better evaluate
the interest of the group.

My opinion is that the "cross-plateform" name is a buzzword and your
group is trying to tie together such a large scale of expertize that it
would be too noisy to be useful. Worse, it would mislead people in
making them believe they can get help from it.

Michael

 

[James Kanze]

Cross-platform programming is distinct from portable
programming. Cross-platform programming is more restrictive,
such as assuming the existence of a keyboard, monitor and
mouse.

That's a new definition for me. In English, cross-platform
really suggests developing on a platform different from the one
you target. For example, you'd probably use a cross-platform
development environment if you were targeting an embedded
processor which didn't have a keyboard.

If you're just talking about how you code, or libraries, then
cross-platform has pretty much the same meaning as portable. In
particular, to be on topic in this group, the posting must be
cross-platform.

Yes but talk about the wxWidgets cross-platform GUI library
isn't particularly fitting, especially when people reply that
the Standard doesn't know what a keyboard is.

There are pricks and idiots everywhere. FWIW: the standard
distinguished between hosted and free standing environments, and
in a hosted environment, between interactive devices and
non-interactive devices. Parts of IO stream, for example, are
explicitly designed to ensure that screen output occurs before
you block for keyboard input. (The actual standard may not use
the words screen and keyboard, but the intent is very, very
clear.)

More generally: if you want to know what GUI libraries are
available, or which one is recommended, then here is the place
to ask. If you want details concerning the API of a particular
library, then you'll probably get better results asking on a
mailing list consacrated to that library. But strictly speaking,
if the library is really portable, like wxWidgets, I don't think
it's really off topic here. (And of course, Boost is explicitly
on topic, since it's goals include becoming "standard C++".)

This has always been the case, since the group was founded.

 

[James Kanze]

On 2008-01-06 20:46, Erik Wikström wrote:

[...]

Let me correct that: Code is portable if it has the ability to
compile/ run on a different platform with little or no
changes. There is no requirement that the portability was
intended.

Code is portable if it has been compiled and runs on different
platforms. Code that has not been tested on different platforms
isn't portable, even if portability was intended.

 

[James Kanze]

comp.lang.c++:

I disagree. My own definition of portable is that the code
will compile and function as intended on every conceivable
implementation of the C++ Standard.

In other words, there's no such thing as portable code.

If you're assuming 8-Bit bytes, then it's not portable.

Portability isn't a yes/no question. There are different
degrees of portability. And unless you've actually compiled and
tested your code on a platform with bytes that aren't 8 bits,
it's not portable to a platform with bytes that aren't 8 bits.

 

[Erik Wikström]

On 2008-01-06 20:46, Erik Wikström wrote:
[...]

Cross-platform programming is distinct from portable
programming. Cross- platform programming is more
restrictive, such as assuming the existence of a keyboard,
monitor and mouse.
I disagree, there are a lot of portable code/applications
out there that makes assumptions about the
machines/environments it will run in. Code is portable if it
has been written with portability (the ability to compile
and run with little or no changes) in mind. It does not
imply that it must be compilable and runnable on every
platform with a C++ compiler.

Let me correct that: Code is portable if it has the ability to
compile/ run on a different platform with little or no
changes. There is no requirement that the portability was
intended.

Code is portable if it has been compiled and runs on different
platforms. Code that has not been tested on different platforms
isn't portable, even if portability was intended.

What you talk about is ported code, the word portability implies that
the the code has the ability to become ported. Or do you mean that the
following is not portable code?

#include <iostream>

int main()
{
std::cout << "This code is portable\n";
}

 

[Christopher]

I disagree. My own definition of portable is that the code will compile and
function as intended on every conceivable implementation of the C++
Standard.

If you're assuming 8-Bit bytes, then it's not portable.

I care less what your opinions, definitions, and feedback are every
time you hijack a post for your silly idea of creating a misnamed
newsgroup to cover topics that are already covered elsewhere. Do any
of the posts from #8 down in this thread have anything to do with the
OP's question?!!