Discussion:
How to pass class-member function to pthread_create(....)?
(too old to reply)
H***@gmail.com
2005-07-15 07:47:38 UTC
Permalink
Hi all:

I want to pass a class-member function to pthread_create, and my
code is in the following, but I don't know how to pass
myobj.thread_function to pthread_create function.

class test
{
public:
test(){}
~test(){}
void thread_function(void*){}
};

int main()
{
test myobj;

pthread_t thrd;

pthread_attr_t attr;
pthread_attr_init(&attr);
pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);

/**************************************************************/
pthread_create(&thrd, &attr, /*????????*/, NULL);
/**************************************************************/

pthread_attr_destroy(&attr);

}



pthread_create(...)'s Syntax

#include <pthread.h>;

int pthread_create (pthread_t *thread, const pthread_attr_t *attr, void
*(*start_routine) (void *), void *arg) ;
Joe Seigh
2005-07-15 11:37:35 UTC
Permalink
Post by H***@gmail.com
I want to pass a class-member function to pthread_create, and my
code is in the following, but I don't know how to pass
myobj.thread_function to pthread_create function.
class test
{
test(){}
~test(){}
void thread_function(void*){}
};
...
Post by H***@gmail.com
pthread_create(...)'s Syntax
#include <pthread.h>;
int pthread_create (pthread_t *thread, const pthread_attr_t *attr, void
*(*start_routine) (void *), void *arg) ;
You'll have to use a static function (with external "C" I believe) that
is used as the function parameter for pthread_create. I will have to
invoke the method. The object and other parameterw will have to be passed
by arg. If just object, a simple cast will do, otherwise they have to be
passed in a structure.
--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.
Vyacheslav Kononenko
2005-07-15 17:37:38 UTC
Permalink
Post by Joe Seigh
You'll have to use a static function (with external "C" I believe) that
is used as the function parameter for pthread_create. I will have to
invoke the method. The object and other parameterw will have to be passed
by arg. If just object, a simple cast will do, otherwise they have to be
passed in a structure.
--
Joe Seigh
It has to match signature that "pthread_create" expects so it has to be
static method or generic function and extern "C" is not necessary. For
example:

class foo {
void thread_function();
public:
static void *static_func( void * ptr) { reinterpret_cast<foo *>( ptr
)->thread_function(); }
};

...
foo *test;
pthread_create( thread, attr, foo::thread_func, test );
...

Regards,
Vyacheslav
Vyacheslav Kononenko
2005-07-15 17:41:21 UTC
Permalink
it should be
pthread_create( thread, attr, foo::static_func, test );
Sorry

Regards,
Vyacheslav
Maciej Sobczak
2005-07-15 20:02:13 UTC
Permalink
Post by Vyacheslav Kononenko
it should be
pthread_create( thread, attr, foo::static_func, test );
No. The closest thing you need is &foo:static_func (note &), but it is
still not correct, since pthread expects pointer to "C" function.
C++ code can provide extern "C" function, but *not* member function,
even if static, because member functions cannot be extern "C".

The trick with static member is popular, but incorrect, at least with
pthreads (but it may work elsewhere, like with Windows API when compiled
with Microsoft compilers).
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
Vyacheslav Kononenko
2005-07-18 13:53:47 UTC
Permalink
Post by Maciej Sobczak
Post by Vyacheslav Kononenko
it should be
pthread_create( thread, attr, foo::static_func, test );
No. The closest thing you need is &foo:static_func (note &), but it is
still not correct, since pthread expects pointer to "C" function.
C++ code can provide extern "C" function, but *not* member function,
even if static, because member functions cannot be extern "C".
The trick with static member is popular, but incorrect, at least with
pthreads (but it may work elsewhere, like with Windows API when compiled
with Microsoft compilers).
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
Hmm if its unsafe to use a different linkage function by a pointer, why
C++ compiler does not warn at least? In ideal it should fail to compile
when I try to assign incompatible pointers, shall it not?.

Regards,
Vyacheslav
Maciej Sobczak
2005-07-18 14:02:09 UTC
Permalink
Post by Vyacheslav Kononenko
Hmm if its unsafe to use a different linkage function by a pointer, why
C++ compiler does not warn at least?
Because you tried the compiler that allows this. It does not make the
code any more correct, though.

As far as I remember, the aCC compiler on HP-UX barks on it, but I'm not
sure about my memory and cannot check it right now. If you have access
to this compiler, please try it.
Post by Vyacheslav Kononenko
In ideal it should fail to compile
when I try to assign incompatible pointers, shall it not?.
Except when the compiler is already used to support a big mass of broken
code, yes.
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
Torsten Robitzki
2005-07-18 14:11:14 UTC
Permalink
Post by Vyacheslav Kononenko
Post by Maciej Sobczak
The trick with static member is popular, but incorrect, at least with
pthreads (but it may work elsewhere, like with Windows API when compiled
with Microsoft compilers).
Hmm if its unsafe to use a different linkage function by a pointer, why
C++ compiler does not warn at least? In ideal it should fail to compile
when I try to assign incompatible pointers, shall it not?.
There are a lot of thinks C++ compiler don't have to warn about. And on
compiler / platforms, where the ABI for static member functions are
equal to those of C functions, there is no technical difference in the
pointer type and it might be hard to implement such a warning.

best regards
Torsten
David Schwartz
2005-07-18 19:06:22 UTC
Permalink
Post by Vyacheslav Kononenko
Hmm if its unsafe to use a different linkage function by a pointer, why
C++ compiler does not warn at least? In ideal it should fail to compile
when I try to assign incompatible pointers, shall it not?.
It's inconvenient to generate a warning (it is just not easy to do).
It's easy to make it just not work, but there's no point in bothering to do
that on platform where it happens to be safe.

DS
David Hopwood
2005-07-18 20:19:10 UTC
Permalink
Post by David Schwartz
Post by Vyacheslav Kononenko
Hmm if its unsafe to use a different linkage function by a pointer, why
C++ compiler does not warn at least? In ideal it should fail to compile
when I try to assign incompatible pointers, shall it not?.
It's inconvenient to generate a warning (it is just not easy to do).
It would be trivial to generate a warning (the function passed to
pthread_create has the wrong type, and compilers usually diagnose type
errors similar to this when the relevant prototype is in scope). Note
however that the original program snippets did not #include <pthread.h>,
which might account for the lack of a warning from some compilers in
this case. Anyway, it's obvious that absence of a warning doesn't imply
that the code will work.
--
David Hopwood <***@blueyonder.co.uk>
Joe Seigh
2005-07-15 17:59:41 UTC
Permalink
Post by Vyacheslav Kononenko
Post by Joe Seigh
You'll have to use a static function (with external "C" I believe) that
is used as the function parameter for pthread_create. I will have to
invoke the method. The object and other parameterw will have to be passed
by arg. If just object, a simple cast will do, otherwise they have to be
passed in a structure.
--
Joe Seigh
It has to match signature that "pthread_create" expects so it has to be
static method or generic function and extern "C" is not necessary. For
class foo {
void thread_function();
static void *static_func( void * ptr) { reinterpret_cast<foo *>( ptr
)->thread_function(); }
};
...
foo *test;
pthread_create( thread, attr, foo::thread_func, test );
...
void * start(void * arg) {
((MyObj *)arg)->func();
return NULL; // or something returned from func
}

or
void * start(void * arg) {
struct somestruct *args = (struct somestruct *)arg;

args->obj->func(args->arg1, ...);
return NULL;
}

You have to explicitly construct the object method invocation. And pthreads
is a *C* library. It can't make calls to C++ methods. If you figure out
how to do that in a portable manner in C, let the posix pthreads committee know.
--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.
Vyacheslav Kononenko
2005-07-16 18:06:02 UTC
Permalink
Post by Joe Seigh
You have to explicitly construct the object method invocation. And pthreads
is a *C* library. It can't make calls to C++ methods. If you figure out
how to do that in a portable manner in C, let the posix pthreads committee know.
--
Joe Seigh
Easily. For compilers where thats incompatible if any just provide
different pthread_create specific for C++. It can be done easilly
because of mangling.

Regards,
Vyacheslav
Chris Thomasson
2005-07-17 08:19:33 UTC
Permalink
Post by Vyacheslav Kononenko
Post by Joe Seigh
You have to explicitly construct the object method invocation. And pthreads
is a *C* library. It can't make calls to C++ methods. If you figure out
how to do that in a portable manner in C, let the posix pthreads committee know.
--
Joe Seigh
Easily. For compilers where thats incompatible if any just provide
different pthread_create specific for C++. It can be done easilly
because of mangling.
I would "study" the responses you get from this group "before" you respond,
if I were you. If you don't do this, you may end up sounding a bit
ignorant...

:O
Chris Thomasson
2005-07-17 08:14:50 UTC
Permalink
Post by Vyacheslav Kononenko
It has to match signature that "pthread_create" expects so it has to be
static method or generic function and extern "C" is not necessary.
Unfortunately extern "C" is necessary if your interested in creating
"correct code"...
Vyacheslav Kononenko
2005-07-18 14:27:42 UTC
Permalink
Post by Chris Thomasson
Post by Vyacheslav Kononenko
It has to match signature that "pthread_create" expects so it has to be
static method or generic function and extern "C" is not necessary.
Unfortunately extern "C" is necessary if your interested in creating
"correct code"...
The problem is using extern "C" does _NOT_ make 100% correct code
either. It could be safer to do that. But could be safer is different
than correct/incorrect statements showed here. I could be wrong but
please provide reference in C++ standard wich says how extern "C"
linkage affect calling conventions then.
Getting ignorance when providing different point of view than common
is this group is very nice "feature". But common and/or most people
opinion is not always correct.

Regards,
Vyacheslav
Chris Thomasson
2005-07-18 16:02:59 UTC
Permalink
Post by Vyacheslav Kononenko
Post by Chris Thomasson
Unfortunately extern "C" is necessary if your interested in creating
"correct code"...
The problem is using extern "C" does _NOT_ make 100% correct code
either. It could be safer to do that. But could be safer is different
than correct/incorrect statements showed here.
I would argue that it is "correct" to use extern "C" for the functions you
pass to a pthreads library; pthreads is a C library after all...

http://groups.google.ca/group/comp.programming.threads/msg/f5c244ebe83e1811?hl=en
Post by Vyacheslav Kononenko
Getting ignorance when providing different point of view than common
is this group is very nice "feature". But common and/or most people
opinion is not always correct.
:)
Vyacheslav Kononenko
2005-07-18 17:15:05 UTC
Permalink
Post by Chris Thomasson
Post by Vyacheslav Kononenko
Post by Chris Thomasson
Unfortunately extern "C" is necessary if your interested in creating
"correct code"...
The problem is using extern "C" does _NOT_ make 100% correct code
either. It could be safer to do that. But could be safer is different
than correct/incorrect statements showed here.
I would argue that it is "correct" to use extern "C" for the functions you
pass to a pthreads library; pthreads is a C library after all...
extern "C" does not gurantee that your C++ function would be correctly
callable from any C code. So I do not agree with statement that says:
"static member solution is incorrect when extern "C" function is". It
could be safer that's all.

Regards,
Vyacheslav
Torsten Robitzki
2005-07-18 18:13:21 UTC
Permalink
Post by Vyacheslav Kononenko
Post by Chris Thomasson
Post by Vyacheslav Kononenko
Post by Chris Thomasson
Unfortunately extern "C" is necessary if your interested in creating
"correct code"...
The problem is using extern "C" does _NOT_ make 100% correct code
either. It could be safer to do that. But could be safer is different
than correct/incorrect statements showed here.
I would argue that it is "correct" to use extern "C" for the functions you
pass to a pthreads library; pthreads is a C library after all...
extern "C" does not gurantee that your C++ function would be correctly
callable from any C code.
So what's the point of declaring a function extern "C" other then make
it callable from C?
Post by Vyacheslav Kononenko
"static member solution is incorrect when extern "C" function is". It
could be safer that's all.
It might work. But why would one gamble and depend on something that
might work if there is an easy approach that is required to work because
there are specifications that guaranties that this approach will work?

regards
Torsten
Vyacheslav Kononenko
2005-07-18 19:50:09 UTC
Permalink
Post by Torsten Robitzki
Post by Vyacheslav Kononenko
Post by Chris Thomasson
Post by Vyacheslav Kononenko
Post by Chris Thomasson
Unfortunately extern "C" is necessary if your interested in creating
"correct code"...
The problem is using extern "C" does _NOT_ make 100% correct code
either. It could be safer to do that. But could be safer is different
than correct/incorrect statements showed here.
I would argue that it is "correct" to use extern "C" for the functions you
pass to a pthreads library; pthreads is a C library after all...
extern "C" does not gurantee that your C++ function would be correctly
callable from any C code.
So what's the point of declaring a function extern "C" other then make
it callable from C?
But make it callable from C is different than guarantee that _ANY_ C
code compiled by _ANY_ C compiler or C++ compiler in C mode with _ANY_
set of options will call extern "C" function correctly, isn't it?
Post by Torsten Robitzki
It might work. But why would one gamble and depend on something that
might work if there is an easy approach that is required to work because
there are specifications that guaranties that this approach will work?
There is no such specifications that the problem. You have to know that
your C library compiler code is compatible with C++ compiler generated
code anyway. And you can know if it is safe to call extern "C++"
linkage from the C library as well.
Post by Torsten Robitzki
regards
Torsten
Regards,
Vyacheslav
David Schwartz
2005-07-18 20:01:27 UTC
Permalink
Post by Vyacheslav Kononenko
Post by Torsten Robitzki
So what's the point of declaring a function extern "C" other then make
it callable from C?
But make it callable from C is different than guarantee that _ANY_ C
code compiled by _ANY_ C compiler or C++ compiler in C mode with _ANY_
set of options will call extern "C" function correctly, isn't it?
Good thing nobody ever claimed anything like that.
Post by Vyacheslav Kononenko
Post by Torsten Robitzki
It might work. But why would one gamble and depend on something that
might work if there is an easy approach that is required to work because
there are specifications that guaranties that this approach will work?
There is no such specifications that the problem. You have to know that
your C library compiler code is compatible with C++ compiler generated
code anyway. And you can know if it is safe to call extern "C++"
linkage from the C library as well.
Huh? The purpose of extern "C" is specifically does ensure that your C++
compiler generated code is compatible with C code. You can know that you
have this compatability by passing '-pthread' to your C++ compiler, which is
guaranteed to provide a compatible (with that compiler) pthreads
implementations.

To put it another way, if your compiler supports pthreads, extern "C"
*must* work. If your compiler does not, nothing will work.

DS
David Hopwood
2005-07-18 20:24:43 UTC
Permalink
Post by David Schwartz
Huh? The purpose of extern "C" is specifically does ensure that your C++
compiler generated code is compatible with C code. You can know that you
have this compatability by passing '-pthread' to your C++ compiler, which is
guaranteed to provide a compatible (with that compiler) pthreads
implementations.
Unfortunately not, even for a certain compiler where -pthread is sometimes
the right option:

<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20705>
--
David Hopwood <***@blueyonder.co.uk>
David Schwartz
2005-07-18 20:44:16 UTC
Permalink
Post by David Hopwood
Post by David Schwartz
Huh? The purpose of extern "C" is specifically does ensure that your
C++ compiler generated code is compatible with C code. You can know that
you have this compatability by passing '-pthread' to your C++ compiler,
which is guaranteed to provide a compatible (with that compiler) pthreads
implementations.
Unfortunately not, even for a certain compiler where -pthread is sometimes
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20705>
Nobody ever said there couldn't be bugs. That some particular platform
has some particular bug that causes it to violate some particular guarantee
in some particular standard doesn't change the fact that the standard
provides the guarantee.

The issue is whether extern C is guaranteed to work and whether it is
guaranteed to work without it. My response is based upon what the standards
say. No implementation details (or bugs) can change what the standards say.

DS
Vyacheslav Kononenko
2005-07-18 20:50:14 UTC
Permalink
Post by David Schwartz
Post by David Hopwood
Post by David Schwartz
Huh? The purpose of extern "C" is specifically does ensure that your
C++ compiler generated code is compatible with C code. You can know that
you have this compatability by passing '-pthread' to your C++ compiler,
which is guaranteed to provide a compatible (with that compiler) pthreads
implementations.
Unfortunately not, even for a certain compiler where -pthread is sometimes
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20705>
Nobody ever said there couldn't be bugs. That some particular platform
has some particular bug that causes it to violate some particular guarantee
in some particular standard doesn't change the fact that the standard
provides the guarantee.
The issue is whether extern C is guaranteed to work and whether it is
guaranteed to work without it. My response is based upon what the standards
say. No implementation details (or bugs) can change what the standards say.
DS
Which standard provides this guarantee? Espeacially about pthread
option. Can you provide such statements from the standard please?

Regards,
Vyacheslav
David Schwartz
2005-07-18 22:09:45 UTC
Permalink
Post by Vyacheslav Kononenko
Which standard provides this guarantee?
The C++ standard provides the guarantee that extern "C" gives C linkage.
The pthreads standard gives the guarantee that pthread_create takes
functions with C linkage.
Post by Vyacheslav Kononenko
Espeacially about pthread
option. Can you provide such statements from the standard please?
The standards don't tell you how to get your platform to support the
standards. But that has nothing whatsoever to do with the issue in this
thread which is about how you write code that complies with the standards.

DS
Vyacheslav Kononenko
2005-07-19 03:39:37 UTC
Permalink
Post by David Schwartz
Post by Vyacheslav Kononenko
Which standard provides this guarantee?
The C++ standard provides the guarantee that extern "C" gives C linkage.
The pthreads standard gives the guarantee that pthread_create takes
functions with C linkage.
I am sorry, but I would like to see what POSIX says about C linkage in
pthread_create, not your comments on that. Can you make a quote?
Post by David Schwartz
Post by Vyacheslav Kononenko
Espeacially about pthread
option. Can you provide such statements from the standard please?
The standards don't tell you how to get your platform to support the
standards. But that has nothing whatsoever to do with the issue in this
thread which is about how you write code that complies with the standards.
You said: "You can know that you have this compatability by passing
'-pthread' to your C++ compiler, which is guaranteed to provide a
compatible (with that compiler) pthreads implementations." I just want
to know whos guaranteed, thats all.
Post by David Schwartz
DS
Regards,
Vyacheslav
Ian
2005-07-19 05:05:56 UTC
Permalink
Post by Vyacheslav Kononenko
Post by David Schwartz
Post by Vyacheslav Kononenko
Which standard provides this guarantee?
The C++ standard provides the guarantee that extern "C" gives C linkage.
The pthreads standard gives the guarantee that pthread_create takes
functions with C linkage.
I am sorry, but I would like to see what POSIX says about C linkage in
pthread_create, not your comments on that. Can you make a quote?
Oh come on, this is purely a language issue between C and C++, nothing
to do with POSIX. pthread_create is a C language interface function, so
you pass it another C language function, not a C++ or Java or anything else.

That's exactly what extern "C" does in C++, it declares that a function
is vanilla C.

Try passing a static member with a pedantic C++ compiler.

Ian
Jedrzej Dudkiewicz
2005-07-19 06:51:08 UTC
Permalink
Post by Vyacheslav Kononenko
Post by David Schwartz
The C++ standard provides the guarantee that extern "C" gives C linkage.
The pthreads standard gives the guarantee that pthread_create takes
functions with C linkage.
I am sorry, but I would like to see what POSIX says about C linkage in
pthread_create, not your comments on that. Can you make a quote?
This http://www.opengroup.org/onlinepubs/007908799/xsh/pthread.h.html says:

The following are declared as functions and may also be declared as macros.
Function prototypes must be provided for use with an ISO C compiler.

So, it's for use with C compiler and this is the way it is used: C header is
included and linking with C library is performed.

C++ Standard says:

7.5.1 All function types, function names, and variable names have a language
linkage. The default language linkage of all function types, function names,
and variable names is C++ language linkage. Two function types with
different language linkages are distinct types even if they are otherwise
identical. (The last sentece was quoted here by Maciej Sobczak)

7.5.2 Linkage between C++ and non-C++ code fragments can be achieved using a
linkage-specification:

linkage-specification:
extern string-literal { delcaration-seq(here goes subscript "opt",
but...) }
extern string-literal declaration

The string-literal indicates the required language linkage. [...]

7.5.3 Every implementation shall provide for linkage to functions written in
the C programming language, "C", and linkage to C++ functions, "C++".

We use C headers and C libraries in C++ code. The only way to achieve it in
C++ is to declare function passed to this libraries as extern "C".

JD
Vyacheslav Kononenko
2005-07-19 13:16:08 UTC
Permalink
[SKIPPED]
We use C headers and C libraries in C++ code. The only way to achieve it in
C++ is to declare function passed to this libraries as extern "C".
JD
Thats simply not true. It is NOT the ONLY way, sorry. Just a sample
from C++ standard (§25.4):

extern "C" void qsort(void* base, size_t nmemb, size_t size,
int (*compar)(const void*, const void*));

extern "C++" void qsort(void* base, size_t nmemb, size_t size,
int (*compar)(const void*, const void*));

Another solution could be to make pthread_create not extern "C" in
header (just default) and provide two version of it in the library -
one for C and one for C++. And thats need to be done only in compiler
where C++ and C functions use different calling conventions.

Regards,
Vycheslav
Jedrzej Dudkiewicz
2005-07-19 14:17:17 UTC
Permalink
Post by Vyacheslav Kononenko
Post by Jedrzej Dudkiewicz
We use C headers and C libraries in C++ code. The only way to achieve it in
C++ is to declare function passed to this libraries as extern "C".
Thats simply not true. It is NOT the ONLY way, sorry. Just a sample
extern "C" void qsort(void* base, size_t nmemb, size_t size,
int (*compar)(const void*, const void*));
extern "C++" void qsort(void* base, size_t nmemb, size_t size,
int (*compar)(const void*, const void*));
Another solution could be to make pthread_create not extern "C" in
header (just default) and provide two version of it in the library -
one for C and one for C++. And thats need to be done only in compiler
where C++ and C functions use different calling conventions.
I am sorry, but I would like to see what POSIX says about C linkage in
pthread_create, not your comments on that. Can you make a quote?
Standard says: Function prototypes must be provided for use with an ISO C
compiler.

I assume, that if interface (function prototypes) is in C, passed data MUST
be C-compatible. Library can be implemented in java or python, but it must
provide C interface.
Post by Vyacheslav Kononenko
You have to know that
your C library compiler code is compatible with C++ compiler generated
code anyway.
No. Your C++ compiler must be compatible with C library compiler. Not the
other way around.
Post by Vyacheslav Kononenko
And you can know if it is safe to call extern "C++"
linkage from the C library as well.
Maybe, but it's not required by any standard, so you can't count on it.

JD
Vyacheslav Kononenko
2005-07-19 17:02:05 UTC
Permalink
Post by Jedrzej Dudkiewicz
Post by Vyacheslav Kononenko
Post by Jedrzej Dudkiewicz
We use C headers and C libraries in C++ code. The only way to achieve it
in
Post by Vyacheslav Kononenko
Post by Jedrzej Dudkiewicz
C++ is to declare function passed to this libraries as extern "C".
Thats simply not true. It is NOT the ONLY way, sorry. Just a sample
extern "C" void qsort(void* base, size_t nmemb, size_t size,
int (*compar)(const void*, const void*));
extern "C++" void qsort(void* base, size_t nmemb, size_t size,
int (*compar)(const void*, const void*));
Another solution could be to make pthread_create not extern "C" in
header (just default) and provide two version of it in the library -
one for C and one for C++. And thats need to be done only in compiler
where C++ and C functions use different calling conventions.
I am sorry, but I would like to see what POSIX says about C linkage in
pthread_create, not your comments on that. Can you make a quote?
Standard says: Function prototypes must be provided for use with an ISO C
compiler.
That does not mean that C++ must use what is provided for ISO C
compiler, does it?
Post by Jedrzej Dudkiewicz
I assume, that if interface (function prototypes) is in C, passed data MUST
be C-compatible. Library can be implemented in java or python, but it must
provide C interface.
I am sorry, but what I got in this group some facts from standards and
many assumtions to link that facts together and then conclusion that is
only right opinion and anything different is false. What if somebody
does not share your assumtion?
Post by Jedrzej Dudkiewicz
Post by Vyacheslav Kononenko
You have to know that
your C library compiler code is compatible with C++ compiler generated
code anyway.
No. Your C++ compiler must be compatible with C library compiler. Not the
other way around.
Post by Vyacheslav Kononenko
And you can know if it is safe to call extern "C++"
linkage from the C library as well.
Maybe, but it's not required by any standard, so you can't count on it.
JD
What is required by a standard and which one, what I can count on?

Regards,
Vyacheslav
Marcin 'Qrczak' Kowalczyk
2005-07-19 18:06:30 UTC
Permalink
Post by Vyacheslav Kononenko
That does not mean that C++ must use what is provided for ISO C
compiler, does it?
The intention of C linkage is linking with C libraries.

It can't be guaranteed formally, because the C++ standard doesn't
rely on the existence of some compatible C compiler, but it works
in practice when it makes sense, i.e. when there is a common C ABI
between the C compiler and the C++ compiler involved.
--
__("< Marcin Kowalczyk
\__/ ***@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
David Schwartz
2005-07-19 19:03:46 UTC
Permalink
Post by Vyacheslav Kononenko
I am sorry, but what I got in this group some facts from standards and
many assumtions to link that facts together and then conclusion that is
only right opinion and anything different is false. What if somebody
does not share your assumtion?
What assumptions are you talking about? The standards are, IMO,
*perfectly* clear about this.
Post by Vyacheslav Kononenko
What is required by a standard and which one, what I can count on?
We pasted numerous excerpts. Read the specification for 'posix_spawn'.

DS
Jedrzej Dudkiewicz
2005-07-20 06:26:08 UTC
Permalink
Post by Vyacheslav Kononenko
Post by Jedrzej Dudkiewicz
Standard says: Function prototypes must be provided for use with an ISO C
compiler.
That does not mean that C++ must use what is provided for ISO C
compiler, does it?
If you want use POSIX threads, you must use ISO C compiler. You can use any
other interface, but this way it's just "some library" based on threads.
Post by Vyacheslav Kononenko
Post by Jedrzej Dudkiewicz
I assume, that if interface (function prototypes) is in C, passed data MUST
be C-compatible. Library can be implemented in java or python, but it must
provide C interface.
I am sorry, but what I got in this group some facts from standards and
many assumtions to link that facts together and then conclusion that is
only right opinion and anything different is false. What if somebody
does not share your assumtion?
Show me these assumptions. C interface? The fact, that, according to C++
standard, C++ links only with C++?
Post by Vyacheslav Kononenko
Post by Jedrzej Dudkiewicz
Post by Vyacheslav Kononenko
And you can know if it is safe to call extern "C++"
linkage from the C library as well.
Maybe, but it's not required by any standard, so you can't count on it.
What is required by a standard and which one, what I can count on?
Sorry, I'm off. Follow David Schwartz's tips: read standards on your own.

JD
David Schwartz
2005-07-19 06:59:47 UTC
Permalink
Post by Vyacheslav Kononenko
Post by David Schwartz
Post by Vyacheslav Kononenko
Which standard provides this guarantee?
The C++ standard provides the guarantee that extern "C" gives C linkage.
The pthreads standard gives the guarantee that pthread_create takes
functions with C linkage.
I am sorry, but I would like to see what POSIX says about C linkage in
pthread_create, not your comments on that. Can you make a quote?
Check the standard yourself, it appears in many, MANY places that the
standard is a C standard and that function pointers have C linkage. In at
least one place, it is totally explicit about this.

DS
Vyacheslav Kononenko
2005-07-19 13:42:54 UTC
Permalink
Post by David Schwartz
Post by Vyacheslav Kononenko
Post by David Schwartz
Post by Vyacheslav Kononenko
Which standard provides this guarantee?
The C++ standard provides the guarantee that extern "C" gives C linkage.
The pthreads standard gives the guarantee that pthread_create takes
functions with C linkage.
I am sorry, but I would like to see what POSIX says about C linkage in
pthread_create, not your comments on that. Can you make a quote?
Check the standard yourself, it appears in many, MANY places that the
standard is a C standard and that function pointers have C linkage. In at
least one place, it is totally explicit about this.
DS
Another question, sorry. Does POSIX says that C++ must use C library
and not to have its own implementation?

Regards,
Vyacheslav
Dragan Cvetkovic
2005-07-19 13:47:16 UTC
Permalink
Post by Vyacheslav Kononenko
Another question, sorry. Does POSIX says that C++ must use C library
and not to have its own implementation?
Is there such a thing as POSIX C++?

Dragan
--
Dragan Cvetkovic,

To be or not to be is true. G. Boole No it isn't. L. E. J. Brouwer

!!! Sender/From address is bogus. Use reply-to one !!!
Vyacheslav Kononenko
2005-07-19 13:53:20 UTC
Permalink
Post by Dragan Cvetkovic
Post by Vyacheslav Kononenko
Another question, sorry. Does POSIX says that C++ must use C library
and not to have its own implementation?
Is there such a thing as POSIX C++?
Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole No it isn't. L. E. J. Brouwer
!!! Sender/From address is bogus. Use reply-to one !!!
Do you always answer by question to question?

Regards,
Vyacheslav
Dragan Cvetkovic
2005-07-19 13:54:23 UTC
Permalink
Post by Vyacheslav Kononenko
Post by Dragan Cvetkovic
Post by Vyacheslav Kononenko
Another question, sorry. Does POSIX says that C++ must use C library
and not to have its own implementation?
Is there such a thing as POSIX C++?
Do you always answer by question to question?
Why not? :-)

Dragan
--
Dragan Cvetkovic,

To be or not to be is true. G. Boole No it isn't. L. E. J. Brouwer

!!! Sender/From address is bogus. Use reply-to one !!!
David Schwartz
2005-07-19 14:00:25 UTC
Permalink
Post by Vyacheslav Kononenko
Another question, sorry. Does POSIX says that C++ must use C library
and not to have its own implementation?
No, it says nothing whatsoever about C++. So this might or might not be
needed and if it's needed, it might or might not be done. So you can't rely
on it.

DS
Thomas Kemmer
2005-07-19 14:06:41 UTC
Permalink
Post by Vyacheslav Kononenko
Another question, sorry. Does POSIX says that C++ must use C library
and not to have its own implementation?
POSIX does not mention C++ at all. The Single UNIX Specification
(System Interfaces) only references ISO C:

1.7 Relationship to Other Formal Standards

Great care has been taken to ensure that this volume of IEEE Std
1003.1-2001 is fully aligned with the following standards:

ISO C (1999)
ISO/IEC 9899:1999, Programming Languages - C.

http://www.unix.org/single_unix_specification/

Regards,
Thomas
David Hopwood
2005-07-20 13:05:28 UTC
Permalink
Post by David Schwartz
Post by David Hopwood
Post by David Schwartz
Huh? The purpose of extern "C" is specifically does ensure that your
C++ compiler generated code is compatible with C code. You can know that
you have this compatability by passing '-pthread' to your C++ compiler,
which is guaranteed to provide a compatible (with that compiler) pthreads
implementations.
Unfortunately not, even for a certain compiler where -pthread is sometimes
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20705>
Nobody ever said there couldn't be bugs. That some particular platform
has some particular bug that causes it to violate some particular guarantee
in some particular standard doesn't change the fact that the standard
provides the guarantee.
No relevant standard provides a guarantee that a conforming compiler will have
a -pthread option that enables pthreads. The nearest thing to that would be
-lpthread in the options to the POSIX c89 and c99 commands (for C, not C++).
Note that the bugzilla entry is for a missing feature ("Severity: enhancement"),
not a bug in the normal sense, despite the bugzilla terminology which calls all
entries bugs.
--
David Hopwood <***@blueyonder.co.uk>
David Schwartz
2005-07-20 20:05:18 UTC
Permalink
Post by David Hopwood
No relevant standard provides a guarantee that a conforming compiler will have
a -pthread option that enables pthreads.
I never said it did.
Post by David Hopwood
The nearest thing to that would be
-lpthread in the options to the POSIX c89 and c99 commands (for C, not C++).
Note that the bugzilla entry is for a missing feature ("Severity: enhancement"),
not a bug in the normal sense, despite the bugzilla terminology which calls all
entries bugs.
I'm sorry, I don't see what this has to do with anything. If we're not
talking about a case where the platform supports pthreads and you know how
to activate it, then what different does it make what 'pthread_create' does
or does not do?

DS
David Hopwood
2005-07-20 20:22:13 UTC
Permalink
Post by David Schwartz
Post by David Hopwood
No relevant standard provides a guarantee that a conforming compiler will
have a -pthread option that enables pthreads.
I never said it did.
You can know that
you have this compatability by passing '-pthread' to your C++ compiler,
which is guaranteed to provide a compatible (with that compiler) pthreads
implementations.
Regardless of what "this compatibility" was referring to, the above sentence
asserts that "passing '-pthread' to your C++ compiler is guaranteed to
provide a compatible (with that compiler) pthreads implementation."
--
David Hopwood <***@blueyonder.co.uk>
David Schwartz
2005-07-20 22:35:38 UTC
Permalink
Post by David Hopwood
Post by David Schwartz
Post by David Hopwood
No relevant standard provides a guarantee that a conforming compiler will
have a -pthread option that enables pthreads.
I never said it did.
You can know that
you have this compatability by passing '-pthread' to your C++ compiler,
which is guaranteed to provide a compatible (with that compiler) pthreads
implementations.
Regardless of what "this compatibility" was referring to, the above sentence
asserts that "passing '-pthread' to your C++ compiler is guaranteed to
provide a compatible (with that compiler) pthreads implementation."
I mean guaranteed by the compiler. Sorry if that wasn't clear. (That is,
it is possible that your compiler provides a simple way to guarantee that
you are getting pthreads compliance.)

But in any event, it's a non-issue. Nobody is either talking about, or
cares about, platforms that don't guarantee pthreads compliance since we are
talking about pthread_create.

DS

Torsten Robitzki
2005-07-18 20:04:02 UTC
Permalink
Post by Vyacheslav Kononenko
Post by Torsten Robitzki
Post by Vyacheslav Kononenko
Post by Chris Thomasson
Post by Vyacheslav Kononenko
Post by Chris Thomasson
Unfortunately extern "C" is necessary if your interested in creating
"correct code"...
The problem is using extern "C" does _NOT_ make 100% correct code
either. It could be safer to do that. But could be safer is different
than correct/incorrect statements showed here.
I would argue that it is "correct" to use extern "C" for the functions you
pass to a pthreads library; pthreads is a C library after all...
extern "C" does not gurantee that your C++ function would be correctly
callable from any C code.
So what's the point of declaring a function extern "C" other then make
it callable from C?
But make it callable from C is different than guarantee that _ANY_ C
code compiled by _ANY_ C compiler or C++ compiler in C mode with _ANY_
set of options will call extern "C" function correctly, isn't it?
One can't make it callable from every C compiler, but from every sane C
compiler on your platform. Extern "C" is a feature of your C++ compiler
and if that compiler don't behave like it it's requested by your
platform ABI it's prety pointless.
Post by Vyacheslav Kononenko
Post by Torsten Robitzki
It might work. But why would one gamble and depend on something that
might work if there is an easy approach that is required to work because
there are specifications that guaranties that this approach will work?
There is no such specifications that the problem. You have to know that
your C library compiler code is compatible with C++ compiler generated
code anyway. And you can know if it is safe to call extern "C++"
linkage from the C library as well.
I would expect a compiler that can't generate code with the requested
linkage to issue an error.

regards
Torsten
Jedrzej Dudkiewicz
2005-07-19 06:54:57 UTC
Permalink
Post by Vyacheslav Kononenko
There is no such specifications that the problem. You have to know that
your C library compiler code is compatible with C++ compiler generated
code anyway.
If it's one compiler, and it's C++ compiler, this must be true.
Post by Vyacheslav Kononenko
And you can know if it is safe to call extern "C++"
linkage from the C library as well.
If you are conforming to C and C++ standard, it is never safe. C standard
doesn't know anything about C++, but C++ knows a lot about C.

JD
Maciej Sobczak
2005-07-18 15:51:03 UTC
Permalink
Post by Vyacheslav Kononenko
please provide reference in C++ standard wich says how extern "C"
linkage affect calling conventions then.
Calling convention has nothing to do about it.

7.5/1:

"Two function types with different language linkages are distinct types
even if they are otherwise identical."

The problem is that converting a function pointer of type "C++" to the
function pointer of type "C" is simply illegal - they are different types.
--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
Vyacheslav Kononenko
2005-07-18 17:24:43 UTC
Permalink
Post by Maciej Sobczak
Post by Vyacheslav Kononenko
please provide reference in C++ standard wich says how extern "C"
linkage affect calling conventions then.
Calling convention has nothing to do about it.
According to link that Chris provided it is the issue:
[While that might work on some platforms, it's not legal C++. The POSIX

standard is a C Language binding, NOT C++. There's no rule that C and
C++
must follow the same calling conventions. In many cases, they do; or at

least it's "close enough" that a C function with a single argument and
a
class member function with no (explicit) arguments are the same.
Counting
on that, though, is just asking for trouble. ]
Post by Maciej Sobczak
"Two function types with different language linkages are distinct types
even if they are otherwise identical."
The problem is that converting a function pointer of type "C++" to the
function pointer of type "C" is simply illegal - they are different types.
Although function types are different function pointers types are not.
Correct me if I am wrong.

Regards,
Vyacheslav
David Schwartz
2005-07-18 19:07:56 UTC
Permalink
Post by Vyacheslav Kononenko
Post by Chris Thomasson
Post by Vyacheslav Kononenko
It has to match signature that "pthread_create" expects so it has to be
static method or generic function and extern "C" is not necessary.
Unfortunately extern "C" is necessary if your interested in creating
"correct code"...
The problem is using extern "C" does _NOT_ make 100% correct code
either. It could be safer to do that. But could be safer is different
than correct/incorrect statements showed here. I could be wrong but
please provide reference in C++ standard wich says how extern "C"
linkage affect calling conventions then.
Getting ignorance when providing different point of view than common
is this group is very nice "feature". But common and/or most people
opinion is not always correct.
What do you think extern "C" does if not allow you to create and call
functions with C linkage?

DS
Loading...