c++ trouble...
Ales Pour
Hi everybody,
I'm in a trouble: g++ doesn't compile the following line:
pthread_cleanup_push((void (*)(void *))0,(void *)0);
Is there something I can do about it?
Thank you.
Ales
Prague,
Czech Republic
Otto Lind
Ales Pour <ro...@hnipak.sh.cvut.cz> wrote:
> I'm in a trouble: g++ doesn't compile the following line:
>
> pthread_cleanup_push((void (*)(void *))0,(void *)0);
>
Is this on a solaris machine? If so, Sun defines pthread_cleanup_push
(and pop) as macros:
#define pthread_cleanup_push(routine, args) { \
_cleanup_t _cleanup_info; \
__pthread_cleanup_push((void (*)(void *))routine, (void *)args, \
(caddr_t)_getfp(), &_cleanup_info);
#define pthread_cleanup_pop(ex) \
__pthread_cleanup_pop(ex, &_cleanup_info); \
}
Note the use of "{" to force the following code in a block. You must use
pthread_cleanup_pop() when using pthread_cleanup_push(). This is
documented in the Solaris cancellation man page. I tried your sample with
a pthread_cleanup_pop(0), and gcc compiles it correctly.
IMHO, if Sun has to use these horrible macros, they should at least
remove the castes to the "routine" and "args" arguments so that
programmers can find argument errors.
Otto
--
Otto Lind Softwire Corporation (North office)
ot...@olcs.com 12125 285th street, Lindstrom, MN 55045
skypoint!olcs!otto voice:(612)257-1259 fax:(612)257-0923
Ales Pour
On 9 Dec 1996, Otto Lind wrote:
> Ales Pour <ro...@hnipak.sh.cvut.cz> wrote:
> > I'm in a trouble: g++ doesn't compile the following line:
> >
> > pthread_cleanup_push((void (*)(void *))0,(void *)0);
> >
>
> Is this on a solaris machine? If so, Sun defines pthread_cleanup_push
> (and pop) as macros:
>
It's linux and linuxthreads but ..._push and ..._pop are macros anyway;
gcc compiles it fine, BUT g++ doesn't.
I didn't know that ..._push and ..._pop must be used in pair; WHY the heck
is this?
Thanks.
Ales
Ales Pour
On Tue, 10 Dec 1996, Ales Pour wrote:
> It's linux and linuxthreads but ..._push and ..._pop are macros anyway;
> gcc compiles it fine, BUT g++ doesn't.
> I didn't know that ..._push and ..._pop must be used in pair; WHY the heck
> is this?
I've just added ..._pop to have *the* pair and the error mesage has
changed to "macro `pthread_cleanup_push' used with just one arg"...
So... ?
Thanks,
Ales
Dave Butenhof
Otto Lind wrote:
>
> Ales Pour <ro...@hnipak.sh.cvut.cz> wrote:
> > I'm in a trouble: g++ doesn't compile the following line:
> > pthread_cleanup_push((void (*)(void *))0,(void *)0);
>
> Is this on a solaris machine? If so, Sun defines pthread_cleanup_push
> (and pop) as macros:
> Note the use of "{" to force the following code in a block. You must use
> pthread_cleanup_pop() when using pthread_cleanup_push(). This is
> documented in the Solaris cancellation man page.
This implementation, by the way, is not some peculiarity of the Solaris
implementation. Digital UNIX defines pthread_cleanup_push and pop as
macros defining a C block, also. And that's exactly the implementation
POSIX was designed to support. The standard specifically requires that
you treat these names as macros expanding so that the push opens a block
and the pop closes that block. They MUST always be paired, at the same
lexical scope.
> IMHO, if Sun has to use these horrible macros, they should at least
> remove the castes to the "routine" and "args" arguments so that
> programmers can find argument errors.
I don't see anything "horrible" about them, but I certainly agree that
it shouldn't be casting the argument types. If the code is right, it's
just wasted characters -- and if the code is wrong, the compiler should
be allowed to diagnose the problem.
/---[ Dave Butenhof ]-----------------------[ bute...@zko.dec.com ]---\
| Digital Equipment Corporation 110 Spit Brook Rd ZKO2-3/Q18 |
| 603.881.2218, FAX 603.881.0120 Nashua NH 03062-2698 |
\-----------------[ Better Living Through Concurrency ]----------------/
Otto Lind
In article <32AEAA...@zko.dec.com>,
Dave Butenhof <bute...@zko.dec.com> writes:
> I don't see anything "horrible" about them, but I certainly agree that
> it shouldn't be casting the argument types. If the code is right, it's
> just wasted characters -- and if the code is wrong, the compiler should
> be allowed to diagnose the problem.
Well, "horrible" may be too strong a term, but the original subject was
"c++ trouble". Since the macros change the scoping under the covers,
this could create the following bug:
foo()
{
int myindex = 22;
while (...)
{
// in while, we are at a new scoping level
pthread_cleanup_push(...)
int myindex = 33; // Scoped within while?
...
pthread_cleanup_pop(...)
...
cout << myindex; // What is this value?
}
}
This would be a subtle error which would not be obvious in inspecting the
code (unless you looked at the C++ code after the preprocessor stage).
Of course _I_ would never write code like the above, but others may, and
some code generators take advantage of this C++ "feature".
> The standard specifically requires that you treat these names as macros
> expanding so that the push opens a block and the pop closes that block.
> They MUST always be paired, at the same lexical scope.
Just curious, Is the standard a "C POSIX" standard? Is there anything in
it to address other language specific issues?
Otto
--
Otto Lind Softwire Corporation (North office)
ot...@olcs.com 12125 285th street, Lindstrom, MN 55045
otto...@softwire.com voice:(612)257-1259 fax:(612)257-0923
Dave Butenhof
Otto Lind wrote:
> > The standard specifically requires that you treat these names as macros
> > expanding so that the push opens a block and the pop closes that block.
> > They MUST always be paired, at the same lexical scope.
>
> Just curious, Is the standard a "C POSIX" standard? Is there anything in
> it to address other language specific issues?
That is exactly the point. POSIX.1 is, specifically and exclusively, a
"C Language" binding. There is also a POSIX.5 series, which is "Ada
Language" bindings, and a POSIX.9 series, which is "FORTRAN Language"
bindings. There are no "C++ Language" bindings to POSIX, nor has there
been any serious proposal of which I'm aware -- certainly none have
gotten so far as a PAR (essentially a POSIX working group charter). Why?
Most likely because C++ is "close enough" to C that POSIX.1 works, even
though a native C++ binding would be easier to use and more flexible.
Using POSIX.1 cleanup handlers in C++ is absurd. Cancellation should be
made to invoke C++ object destructors, at an absolute minimum, instead.
Optionally, one might want to be able to use catch to finalize a Cancel
exception -- allowing the program to recover and continue. (While, in
most cases, a program should always reraise a cancel so the thread can
terminate, there are a few legitimate needs for a true exception-based
implementation.) But ANSI C doesn't have exceptions, or destructors, so
POSIX.1 invented cleanup handlers instead. And, because there's no
requirement (other than logic and reason) that a system's C++ compiler
and POSIX.1c implementation be integrated in any sane way, many C++
programmers (and anyone who wants to write fully portable code) is stuck
with the lowest common denominator.
Reality is a point of view
+---- bute...@zko.dec.com wrote (Tue, 17 Dec 1996 05:00:27 -0500):
| Most likely because C++ is "close enough" to C that POSIX.1 works, even
| though a native C++ binding would be easier to use and more flexible.
The C++ standard is still a draft. That might be an additional
reason.
--
Gary Johnson "Wahoo."
gjoh...@season.com <a href="http://www.marijuana.org/">Remember why...</a>