From: skaller <skaller@users.sourceforge.net>
To: Xavier Leroy <Xavier.Leroy@inria.fr>
Cc: David McClain <dmcclain1@mindspring.com>,
Brian Hurt <bhurt@spnz.org>, caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] C++ Throws
Date: 28 Aug 2004 19:24:08 +1000 [thread overview]
Message-ID: <1093685048.15255.1795.camel@pelican.wigram> (raw)
In-Reply-To: <20040828081743.GA1229@yquem.inria.fr>
On Sat, 2004-08-28 at 18:17, Xavier Leroy wrote:
> There are indeed two "schools" of exception handling: one that unwind
> stack frames one by one until an exception handler is found, and one
> that maintains at run-time a chaining between exception handling
> blocks on the stack, so that no stack searching is necessary when an
> exception is thrown.
>
> The first school is exemplified by C++, Modula-3, Java and C#; the
> second school by Lisp, Caml and to some extent Prolog (if you view
> backtracking as a generalization of exception handling).
C++ is required by the ISO Standard
to unwind each frame to the handler, executing
destructors in FILO order. Ocaml doesn't need to do that,
it has a garbage collector which finalises blocks out of order.
> The two approaches have very different performance trade-offs. To
> make things worse, many people from the first school are not even
> aware of the second approach. So, as usual, there is no hope to see
> the world converge on a single exception mechanism.
As above -- for C++ it is tied up with the requirement
to execute destructors of stacked objects in a FIFO manner.
Simply dropping back to the handler isn't an option.
So it isn't necessarily ignorance that will prevent
convergence -- there are distinct architectural models
to consider, in this finalisation in C++ must be
FILO in both normal and exceptional exits --
C++ code is allowed to rely on destructors executing
in reverse order to constructors.
> > How in the world would any kind of cross-language
> > interoperability ever function if this were the case.
The C++ committee was only ever concerned with
C interoperability. Its not their job to consider
other languages, especially ones that do not
have ISO Standards backing them, where inter-committee
liason is impossible.
> For the reverse direction (Caml calling C++), I'm afraid the only
> solution is to use a C++ catch-all clause to turn C++ exceptions into
> Caml exceptions.
Which can't be done in a portable manner: since the catch-all
cannot have an associated static type, you can't actually
refer to the exception object in the handler.
Other languages -- Java and now Python -- have a top
level exception type from which all exceptions must
be derived. In C++, the type doesn't even have to
be polymorphic -- you can throw an int or string
if you want. Perhaps that's stupid but the reason
is compatibility with earlier C++ code which typically
threw int or char *.
--
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850,
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
next prev parent reply other threads:[~2004-08-28 9:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-27 22:31 David McClain
2004-08-27 23:24 ` Brian Hurt
2004-08-28 0:11 ` David McClain
2004-08-28 1:40 ` skaller
2004-08-28 4:13 ` David McClain
2004-08-28 4:55 ` David Brown
2004-08-28 7:44 ` Ville-Pertti Keinonen
2004-08-28 7:48 ` Radu-Mihail Obada
2004-08-28 8:17 ` Xavier Leroy
2004-08-28 9:24 ` skaller [this message]
2004-08-28 9:31 ` skaller
2004-08-28 0:22 ` David McClain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1093685048.15255.1795.camel@pelican.wigram \
--to=skaller@users.sourceforge.net \
--cc=Xavier.Leroy@inria.fr \
--cc=bhurt@spnz.org \
--cc=caml-list@inria.fr \
--cc=dmcclain1@mindspring.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox