Thread function and C++
qazmlp
function. But, why it is possible for the non-static function?
Is it a must to have a 'C' linkage function(extern "C" ) as the thread
function? Why?
Artie Gold
> I understand that static class member function can be a thread
> function.
Assuming you're thinking of a pthreads implementation, you understand
wrong. It's invoking undefined behavior. Since one of the possibilities
included in UB is that it works (or at least seems to for a given
platform), that's what you're seeing.
> But, why it is possible for the non-static function?
Huh?
>
> Is it a must to have a 'C' linkage function(extern "C" ) as the thread
> function? Why?
Because it's a C library. C++ has a defined interface to C - "C" linkage.
HTH,
--ag
--
Artie Gold -- Austin, Texas
Ulrich Eckhardt
> I understand that static class member function can be a thread
> function. But, why it is possible for the non-static function?
Assuming you meant _IM_possible, the answer is in the FAQ (see my .sig). It
is about the difference between a member-function-pointer and a
function-pointer.
hth
Uli
--
Questions ?
see C++-FAQ Lite: http://parashift.com/c++-faq-lite/ first !
Alexander Terekhov
Ulrich Eckhardt wrote:
[...]
> Assuming you meant _IM_possible, the answer is in the FAQ (see my .sig).
http://groups.google.com/groups?selm=3EE9DE88.F3A7C600%40web.de
(Subject: Re: implementing a Timer class)
<Forward Inline, "abridged">
-----Original Message-----
From: Alexander Terekhov [mailto:tere...@web.de]
Sent: Saturday, June 14, 2003 12:06 PM
To: <snip>@parashift.com
Subject: Re: implementing a Timer class
<snip>@parashift.com schrieb am 13.06.03 21:51:14:
>
> Alexander,
>
> Why would you say "and forget it" regarding section 33 of the FAQ? That
> section contains a FAQ that directly answers the OP's question.
Nope.
> Surely you're not suggesting that the only valid answer to any question
> on clc++ is to quote the standard??
I'm not suggesting that. The problem is that that section is a sort of
misleading, to my taste. It doesn't address the linkage (C linkage is
required) and "POFness" that's needed for signal handlers. And as for
thread routines (and alike), well,
http://groups.google.com/groups?selm=3ECB8F71.689E551C%40web.de
http://groups.google.com/groups?selm=3ECE1254.20134D8B%40web.de
(Subject: Re: Getting the address of a member function)
regards,
alexander.
Ulrich Eckhardt
> Ulrich Eckhardt wrote:
> [...]
>> Assuming you meant _IM_possible, the answer is in the FAQ (see my .sig).
> [...]
>> Questions ?
>> see C++-FAQ Lite: http://parashift.com/c++-faq-lite/ first !
>
> http://groups.google.com/groups?selm=3EE9DE88.F3A7C600%40web.de
> (Subject: Re: implementing a Timer class)
Valid objection ... did you communicate with Marshall Cline about that
section and a possible fix ?
Quoting from above link:
"A POF (``plain old function'') is a function that uses only
features from this common subset, and that does not directly
or indirectly use any function that is not a POF."
And combining it with this:
> The problem is that that section is a sort of
> misleading, to my taste. It doesn't address the linkage (C linkage is
> required) and "POFness" that's needed for signal handlers. And as for
> thread routines (and alike)
[...]
This means that I cannot use C++ which is not valid C in a Pthread, not
even indirectly by calling it from a C-function. Is it really that what
you mean ? Or is it rather a defect in the standard than in a real
application ?
Ulrich Eckhardt
Alexander Terekhov
Ulrich Eckhardt wrote:
>
> Alexander Terekhov wrote:
> > Ulrich Eckhardt wrote:
> > [...]
> >> Assuming you meant _IM_possible, the answer is in the FAQ (see my .sig).
> > [...]
> >> Questions ?
> >> see C++-FAQ Lite: http://parashift.com/c++-faq-lite/ first !
> >
> > http://groups.google.com/groups?selm=3EE9DE88.F3A7C600%40web.de
> > (Subject: Re: implementing a Timer class)
>
> Valid objection ... did you communicate with Marshall Cline about that
> section and a possible fix ?
He contacted me via an "off-band" reply (I just hate that) to my
c.l.c++ posting referenced above. The forwarded message was sent
to him. (He replied with just two words "Wow. Marshall"... and I
really liked that ;-) )
>
> Quoting from above link:
> "A POF (``plain old function'') is a function that uses only
> features from this common subset, and that does not directly
> or indirectly use any function that is not a POF."
>
> And combining it with this: ...
The full quote is this:
"The common subset of the C and C++ languages consists of all
declarations, definitions, and expressions that may appear in
a well formed C++ program and also in a conforming C program.
A POF (``plain old function'') is a function that uses only
features from this common subset, and that does not directly
or indirectly use any function that is not a POF. All signal
handlers shall have C linkage. A POF that could be used as a
signal handler in a conforming C program does not produce
undefined behavior when used as a signal handler in a C++
program. The behavior of any other function used as a signal
handler in a C++ program is implementation defined."
> > The problem is that that section is a sort of
> > misleading, to my taste. It doesn't address the linkage (C linkage is
> > required) and "POFness" that's needed for signal handlers. And as for
> > thread routines (and alike)
> [...]
>
> This means that I cannot use C++ which is not valid C in a Pthread, not
> even indirectly by calling it from a C-function.
The C++ standard currently knows nothing about Pthreads. It does
know about signal handers, however. The C++ standard "insists" on
POFness of signal handlers in "fully portable" C++ applications.
> Is it really that what
> you mean ? Or is it rather a defect in the standard than in a real
> application ?
Yeah. Sort of "a defect".
http://groups.google.com/groups?selm=3F09229F.EFC2CE07%40web.de
(Subject: Re: [OT, welcome msg, link] thread programming with c++)
regards,
alexander.
--
http://groups.google.com/groups?selm=3F128D3D.BD85E692%40web.de
http://groups.google.com/groups?selm=3F129D44.3D6FFA70%40web.de
(Subject: Re: relative precedence of ?: and assignment)