From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id GAA26763; Sat, 28 Aug 2004 06:12:17 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id GAA26459 for ; Sat, 28 Aug 2004 06:12:16 +0200 (MET DST) Received: from asmtp-a063f33.pas.sa.earthlink.net (asmtp-a063f33.pas.sa.earthlink.net [207.217.120.149]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id i7S4CF0A030984 for ; Sat, 28 Aug 2004 06:12:15 +0200 Received: from 168-103-58-53.tcsn.qwest.net ([168.103.58.53] helo=dylan) by asmtp-a063f33.pas.sa.earthlink.net with asmtp (Exim 4.34) id 1C0uZX-00027D-KM; Fri, 27 Aug 2004 21:12:11 -0700 Message-ID: <001201c48cb5$73239ee0$0401000a@dylan> From: "David McClain" To: Cc: "Brian Hurt" , "caml-list" References: <000901c48c93$9bc9eec0$0201000a@dylan> <1093657249.15255.1712.camel@pelican.wigram> Subject: Re: [Caml-list] C++ Throws Date: Fri, 27 Aug 2004 21:13:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-ELNK-Trace: 7a0ab3eafc8cf994b22988ad1c62733440683398e744b8a43505ed085ee097f004617466aaf3662a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 168.103.58.53 X-Miltered: at concorde with ID 4130061F.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; mcclain:01 dmcclain:01 caml-list:01 pants:99 unhandled:01 abort:01 pointers:01 closures:01 runtime:01 aborting:01 aborts:01 sourceforge:01 mcclain:01 dmcclain:01 caml-list:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Okay Skaller... (John, isn't it?) Smarty pants... you may be very correct about most of this, but I can show you that an unhandled throw is being turned into a call to abort() from which there is no recovery. I do find it amazing that C++ would be dumb enough to try to scaffold raw stack frames, instead of using some kind of dynamic link pointers to reach each frame C++. How in the world would any kind of cross-language interoperability ever function if this were the case. Mind you I'm not disputing your estimate here, it's just that I find it a bit incredulous. But whatever, at least with pseudo-functional closures I can handle this problem the way that seems most natural, and down at the module level where it probably belongs, even if it is more expensive in code and runtime. What matters is programmer productivity and being able to prevent the application from aborting just because of an indexing error. This is an interactive application and abrupt aborts aren't very pleasant for the user, nor are they necessary. - DM ----- Original Message ----- From: "skaller" To: "David McClain" Cc: "Brian Hurt" ; "caml-list" Sent: Friday, August 27, 2004 18:40 Subject: Re: [Caml-list] C++ Throws > On Sat, 2004-08-28 at 10:11, David McClain wrote: > > Hi Brian, > > > > Yes, that technique is the one that I said previously works just fine. I was > > hoping for a higher level generic handler, instead of wrapping each > > individual lib call with this try-catch block. > > > > I have been doing C++ to OCaml for years now with no difficulty. The catch > > here is that OCaml appears to be interposing between the established higher > > level catch handlers and the source of the throw exceptions. It appears to > > insist on not allowing any lower dynamic exceptions to propagate above its > > interface with a C call. > > No, I doubt that. What's actually happening is quite the opposite. > C++ stack unwinding involves synchonously destroying stack > objects and NOT returning control until the handler is reached. > > But you've stuck some Ocaml stack frames in the way. > Far from Ocaml 'grabbing control', it isn't doing anything. > Ocaml isn't ever getting control -- C++ knows nothing > and just keeps going -- it doesn't execute the > 'return' instruction for the callers program counter, > it throws it away. > > Actually it's more complex than that -- EH has two jobs: > (a) locate the handler > (b) unwind the stack up to it then give it control > > It is allowed to unwind the stack whilst looking > for the handler. > > It is also allowed to locate the handler FIRST, > and THEN unwind. In particular if there is NO handler, > it is allowed to core dump on the spot without unwinding > anything -- the reason being that you then get a dump > which actually includes debugging information :) > > Either way it is C++ which will either abort() > because it can't find a handler, or corrupt > your system and lock up or crash, if it it actually > get stuck misinterpreting the Ocaml stack frames > either during unwinding or trying to find > the stack frames .. don't even count on abort() > being called. > > I think it is possible to write generic handler, > but only if you have detailed implemention details > from you compiler vendor on how EH is implemented > on your platform :( > > > -- > 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 > ------------------- 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