This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [basic-improvements] try/finally support for c/c++ - more tests
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Michael Matz <matz at suse dot de>, Zack Weinberg <zack at codesourcery dot com>,Richard Henderson <rth at redhat dot com>,Jakub Jelinek <jakub at redhat dot com>, Aldy Hernandez <aldyh at redhat dot com>,"gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>,"jason at redhat dot com" <jason at redhat dot com>
- Date: Thu, 7 Nov 2002 12:20:03 -0500
- Subject: Re: [basic-improvements] try/finally support for c/c++ - more tests
- References: <20021107163818.GA20901@nevyn.them.org> <31220000.1036688822@warlock.codesourcery.com>
On Thu, Nov 07, 2002 at 09:07:02AM -0800, Mark Mitchell wrote:
> Our goals, then, seem to be:
>
> (1) Make life easier for C++ programmers by calling cleanups as
> exceptions propagate. (This can already be managed explicitly,
> with try/catch, but if we can fold it into the library, that's
> a good QOI thing. We do have to be very careful to document it;)
>
> (2) Shield GNU libc developers from having to write the few bits of
> the library that they want to be exception-safe in C++.
>
> The second bit carries no weight with me at all. It's no big deal to
> write a few source files in the C++ almost-superset of C.
It is when they're written in gnu99. It's also a royal pain to require
a C++ compiler when building glibc; bootstrapping gets harder every
day...
> The first bit is, however, a good, user-focused idea.
>
> But why not just do that at the source level? In pthread.h:
Then you require that all pthread_cleanup_push's which need to
be unwound properly be written in C++ source files. In other words,
using these in a library now requires that part of the library to be
converted to C++ in order to be used from C++ safely. Not just talking
the implementation of GNU libc here; all libraries which use pthreads
cleanups.
I'm sure there are other reasons but I've started to lose track of them
in this discussion, so I'll step back now. I also approve of the
extension on its own...
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer