* RE: #define catch?
@ 2000-08-02 8:42 Bossom, John
2000-08-02 9:50 ` Scott McCaskill
0 siblings, 1 reply; 6+ messages in thread
From: Bossom, John @ 2000-08-02 8:42 UTC (permalink / raw)
To: 'Ross Johnson', Scott McCaskill; +Cc: pthreads-win32
"catch" is actually a keyword in C++...
-----Original Message-----
From: Ross Johnson [ mailto:rpj@ise.canberra.edu.au ]
Sent: Wednesday, August 02, 2000 2:27 AM
To: Scott McCaskill
Cc: pthreads-win32@sourceware.cygnus.com
Subject: Re: #define catch?
Scott McCaskill wrote:
>
> I noticed that pthread.h has a macro that defines 'catch'. (macro
> reproduced here for convenience)
>
> /*
> * Redefine the C++ catch keyword to ensure that applications
> * propagate our internal exceptions up to the library's internal
handlers.
> */
> #define catch(E) \
> catch(Pthread_exception_cancel) \
> { \
> throw; \
> } \
> catch(Pthread_exception_exit) \
> { \
> throw; \
> } \
> catch(E)
>
> This breaks the following legal C++ code (because there will be multiple
> catch blocks for Pthread_exception_cancel and Pthread_exception_exit):
>
> try {
> // ...
> }
>
> catch ( some_exception ) { }
>
> catch ( some_other_exception ) { }
Hmmm. When I tested this a long time back the macro seemed to be
harmless. The duplication of catch(Pthread_exception_*)
blocks appeared to not affect other exception catch blocks. Maybe
my testing wasn't good enough. I've been assuming that only
the first matching block is executed and duplicates are redundant
but ok.
Without this any catch(...) inside a thread will prevent
cancelation or pthread_exit() from working for that thread.
I'm currently looking into this since I'm not happy with the
current scheme myself. If anyone has any ideas on how to
handle this then please let me know, I'm short on C++ experience.
Ross
>
> Is this breakage really necessary? I understand the reason for this
macro,
> but perhaps it should at least be optional? For now, I checked out the
tree
> and commented it out to work around it (admittedly not a great solution,
but
> I'm not going to rewrite all my code to only use one catch per try).
>
--
+----------------------+---+
| Ross Johnson | | E-Mail: rpj@ise.canberra.edu.au
| Info Sciences and Eng|___|
| University of Canberra | FAX: +61 6 2015227
| PO Box 1 |
| Belconnen ACT 2616 | WWW: http://willow.canberra.edu.au/~rpj/
| AUSTRALIA |
+--------------------------+
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: #define catch?
2000-08-02 8:42 #define catch? Bossom, John
@ 2000-08-02 9:50 ` Scott McCaskill
2000-08-03 9:11 ` Followup -- " Scott McCaskill
0 siblings, 1 reply; 6+ messages in thread
From: Scott McCaskill @ 2000-08-02 9:50 UTC (permalink / raw)
To: pthreads-win32
----- Original Message -----
From: "Bossom, John" <John.Bossom@Cognos.COM>
To: "'Ross Johnson'" <rpj@ise.canberra.edu.au>; "Scott McCaskill"
<scott@3dfx.com>
Cc: <pthreads-win32@sourceware.cygnus.com>
Sent: Wednesday, August 02, 2000 10:42 AM
Subject: RE: #define catch?
> "catch" is actually a keyword in C++...
>
This is true.. but I don't see what you're getting at. The fundamental
problem I encountered is that this (legal) code:
catch ( app_exception ) { }
catch ( some_other_app_exception ) { }
..will be expanded to the following when using the macro in pthread.h:
catch ( Pthread_exception_cancel ) { throw; }
catch ( Pthread_exception_exit ) { throw; }
catch ( app_exception ) { }
catch ( Pthread_exception_cancel ) { throw; }
catch ( Pthread_exception_exit ) { throw; }
catch ( some_other_app_exception ) { }
..and VC++ will not compile that because of the existence of multiple
handlers for Pthread_exception_cancel and Pthread_exception_exit.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Followup -- Re: #define catch?
2000-08-02 9:50 ` Scott McCaskill
@ 2000-08-03 9:11 ` Scott McCaskill
2000-08-03 20:14 ` Ross Johnson
0 siblings, 1 reply; 6+ messages in thread
From: Scott McCaskill @ 2000-08-03 9:11 UTC (permalink / raw)
To: pthreads-win32
Well, after doing some more research, it appears that it *is* legal in C++
to have multiple catch blocks for the same exception, so apparently this is
yet another VC++ bug.
----- Original Message -----
From: "Scott McCaskill" <scott@3dfx.com>
To: <pthreads-win32@sourceware.cygnus.com>
Sent: Wednesday, August 02, 2000 11:49 AM
Subject: Re: #define catch?
>
> ----- Original Message -----
> From: "Bossom, John" <John.Bossom@Cognos.COM>
> To: "'Ross Johnson'" <rpj@ise.canberra.edu.au>; "Scott McCaskill"
> <scott@3dfx.com>
> Cc: <pthreads-win32@sourceware.cygnus.com>
> Sent: Wednesday, August 02, 2000 10:42 AM
> Subject: RE: #define catch?
>
>
> > "catch" is actually a keyword in C++...
> >
>
> This is true.. but I don't see what you're getting at. The fundamental
> problem I encountered is that this (legal) code:
>
> catch ( app_exception ) { }
> catch ( some_other_app_exception ) { }
>
> ..will be expanded to the following when using the macro in pthread.h:
>
> catch ( Pthread_exception_cancel ) { throw; }
> catch ( Pthread_exception_exit ) { throw; }
> catch ( app_exception ) { }
> catch ( Pthread_exception_cancel ) { throw; }
> catch ( Pthread_exception_exit ) { throw; }
> catch ( some_other_app_exception ) { }
>
> ..and VC++ will not compile that because of the existence of multiple
> handlers for Pthread_exception_cancel and Pthread_exception_exit.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Followup -- Re: #define catch?
2000-08-03 9:11 ` Followup -- " Scott McCaskill
@ 2000-08-03 20:14 ` Ross Johnson
0 siblings, 0 replies; 6+ messages in thread
From: Ross Johnson @ 2000-08-03 20:14 UTC (permalink / raw)
To: Scott McCaskill; +Cc: pthreads-win32
Scott McCaskill wrote:
>
> Well, after doing some more research, it appears that it *is* legal in C++
> to have multiple catch blocks for the same exception, so apparently this is
> yet another VC++ bug.
In any case, the library aims to work in it's target environments and so
I'm still seeking a way to handle this that is portable. Unfortunately,
thus far I haven't been able to come up with a neat, clean and
transparent
method.
The best I've come up with for VC++ (leaving the current macro
defined for other compilers) is the following:
#ifdef NEED_ALTCATCHALL
#warning Replace any 'catch(...)' with 'AltCatchAll' if you want \
Pthread-Win32 cancelation and pthread_exit to work.
#define AltCatchAll \
catch(Pthread_exception) { throw; } \
catch(...)
#else
#define catch(e) \
catch(Pthread_exception) { throw; } \
catch(e)
#endif
[I've now grouped internal library exceptions under a single base
class.]
The application code would need this also for portability:
#include <pthread.h>
#if defined(NEED_ALTCATCHALL) && ! defined(AltCatchAll)
#define AltCatchAll catch(...)
#endif
So unless anyone can offer an alternative I will use this.
Ross
>
> ----- Original Message -----
> From: "Scott McCaskill" <scott@3dfx.com>
> To: <pthreads-win32@sourceware.cygnus.com>
> Sent: Wednesday, August 02, 2000 11:49 AM
> Subject: Re: #define catch?
>
> >
> > ----- Original Message -----
> > From: "Bossom, John" <John.Bossom@Cognos.COM>
> > To: "'Ross Johnson'" <rpj@ise.canberra.edu.au>; "Scott McCaskill"
> > <scott@3dfx.com>
> > Cc: <pthreads-win32@sourceware.cygnus.com>
> > Sent: Wednesday, August 02, 2000 10:42 AM
> > Subject: RE: #define catch?
> >
> >
> > > "catch" is actually a keyword in C++...
> > >
> >
> > This is true.. but I don't see what you're getting at. The fundamental
> > problem I encountered is that this (legal) code:
> >
> > catch ( app_exception ) { }
> > catch ( some_other_app_exception ) { }
> >
> > ..will be expanded to the following when using the macro in pthread.h:
> >
> > catch ( Pthread_exception_cancel ) { throw; }
> > catch ( Pthread_exception_exit ) { throw; }
> > catch ( app_exception ) { }
> > catch ( Pthread_exception_cancel ) { throw; }
> > catch ( Pthread_exception_exit ) { throw; }
> > catch ( some_other_app_exception ) { }
> >
> > ..and VC++ will not compile that because of the existence of multiple
> > handlers for Pthread_exception_cancel and Pthread_exception_exit.
> >
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: #define catch?
2000-08-01 10:27 Scott McCaskill
@ 2000-08-01 23:27 ` Ross Johnson
0 siblings, 0 replies; 6+ messages in thread
From: Ross Johnson @ 2000-08-01 23:27 UTC (permalink / raw)
To: Scott McCaskill; +Cc: pthreads-win32
Scott McCaskill wrote:
>
> I noticed that pthread.h has a macro that defines 'catch'. (macro
> reproduced here for convenience)
>
> /*
> * Redefine the C++ catch keyword to ensure that applications
> * propagate our internal exceptions up to the library's internal handlers.
> */
> #define catch(E) \
> catch(Pthread_exception_cancel) \
> { \
> throw; \
> } \
> catch(Pthread_exception_exit) \
> { \
> throw; \
> } \
> catch(E)
>
> This breaks the following legal C++ code (because there will be multiple
> catch blocks for Pthread_exception_cancel and Pthread_exception_exit):
>
> try {
> // ...
> }
>
> catch ( some_exception ) { }
>
> catch ( some_other_exception ) { }
Hmmm. When I tested this a long time back the macro seemed to be
harmless. The duplication of catch(Pthread_exception_*)
blocks appeared to not affect other exception catch blocks. Maybe
my testing wasn't good enough. I've been assuming that only
the first matching block is executed and duplicates are redundant
but ok.
Without this any catch(...) inside a thread will prevent
cancelation or pthread_exit() from working for that thread.
I'm currently looking into this since I'm not happy with the
current scheme myself. If anyone has any ideas on how to
handle this then please let me know, I'm short on C++ experience.
Ross
>
> Is this breakage really necessary? I understand the reason for this macro,
> but perhaps it should at least be optional? For now, I checked out the tree
> and commented it out to work around it (admittedly not a great solution, but
> I'm not going to rewrite all my code to only use one catch per try).
>
--
+----------------------+---+
| Ross Johnson | | E-Mail: rpj@ise.canberra.edu.au
| Info Sciences and Eng|___|
| University of Canberra | FAX: +61 6 2015227
| PO Box 1 |
| Belconnen ACT 2616 | WWW: http://willow.canberra.edu.au/~rpj/
| AUSTRALIA |
+--------------------------+
^ permalink raw reply [flat|nested] 6+ messages in thread
* #define catch?
@ 2000-08-01 10:27 Scott McCaskill
2000-08-01 23:27 ` Ross Johnson
0 siblings, 1 reply; 6+ messages in thread
From: Scott McCaskill @ 2000-08-01 10:27 UTC (permalink / raw)
To: pthreads-win32
I noticed that pthread.h has a macro that defines 'catch'. (macro
reproduced here for convenience)
/*
* Redefine the C++ catch keyword to ensure that applications
* propagate our internal exceptions up to the library's internal handlers.
*/
#define catch(E) \
catch(Pthread_exception_cancel) \
{ \
throw; \
} \
catch(Pthread_exception_exit) \
{ \
throw; \
} \
catch(E)
This breaks the following legal C++ code (because there will be multiple
catch blocks for Pthread_exception_cancel and Pthread_exception_exit):
try {
// ...
}
catch ( some_exception ) { }
catch ( some_other_exception ) { }
Is this breakage really necessary? I understand the reason for this macro,
but perhaps it should at least be optional? For now, I checked out the tree
and commented it out to work around it (admittedly not a great solution, but
I'm not going to rewrite all my code to only use one catch per try).
Excellent library, BTW.. I'm quite happy to not have to rewrite a bunch of
thread synchronization code for multiple platforms.
--Scott McCaskill
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2000-08-03 20:14 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-08-02 8:42 #define catch? Bossom, John
2000-08-02 9:50 ` Scott McCaskill
2000-08-03 9:11 ` Followup -- " Scott McCaskill
2000-08-03 20:14 ` Ross Johnson
-- strict thread matches above, loose matches on Subject: below --
2000-08-01 10:27 Scott McCaskill
2000-08-01 23:27 ` Ross Johnson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).