www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD now does Dwarf style exception handling!

reply Walter Bright <newshound2 digitalmars.com> writes:
What I've been working on for the last month or so.

https://github.com/D-Programming-Language/dmd/pull/5324

For Linux 64 anyway. Anyone who wants to do PRs to extend it to Linux 32, OSX 
and FreeBSD, feel free! Unfortunately, this is of no help with Win64, which
uses 
its own unique system. DMD for Win32 already can catch C++ exceptions, but
Win32 
is a dead platform.

This is an enabling technology that will confer on D the ability to catch C++ 
exceptions, which is key to interaction with native C++ libraries.

Next up: actually catching C++ exceptions!

Thanks to everyone who helped out with this.
Jan 02
next sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Saturday, 2 January 2016 at 21:16:38 UTC, Walter Bright wrote:
 What I've been working on for the last month or so.

 https://github.com/D-Programming-Language/dmd/pull/5324

 For Linux 64 anyway. Anyone who wants to do PRs to extend it to 
 Linux 32, OSX and FreeBSD, feel free! Unfortunately, this is of 
 no help with Win64, which uses its own unique system. DMD for 
 Win32 already can catch C++ exceptions, but Win32 is a dead 
 platform.

 This is an enabling technology that will confer on D the 
 ability to catch C++ exceptions, which is key to interaction 
 with native C++ libraries.

 Next up: actually catching C++ exceptions!

 Thanks to everyone who helped out with this.
Congrats! What is involved in catching C++ exceptions? Was this the hard part of the whole thing?
Jan 02
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/2/2016 4:17 PM, Jack Stouffer wrote:
 What is involved in catching C++ exceptions? Was this the hard part of the
whole
 thing?
DMD doesn't catch them yet. But C++ on Linux throws them in Dwarf format, so supporting that is the first step.
Jan 02
parent reply Temtaime <temtaime gmail.com> writes:
On Sunday, 3 January 2016 at 02:05:38 UTC, Walter Bright wrote:
 On 1/2/2016 4:17 PM, Jack Stouffer wrote:
 What is involved in catching C++ exceptions? Was this the hard 
 part of the whole
 thing?
DMD doesn't catch them yet. But C++ on Linux throws them in Dwarf format, so supporting that is the first step.
Useless work. Almost nobody will throw exceptions from C++ code to D code. Same old same old : Walter could fix regressions, but instead he found a new nice useless toy to play, and after that, it will be a cause of new regressions. That's why D is always dead in the water.
Jan 04
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, 5 January 2016 at 01:39:51 UTC, Temtaime wrote:
 On Sunday, 3 January 2016 at 02:05:38 UTC, Walter Bright wrote:
 On 1/2/2016 4:17 PM, Jack Stouffer wrote:
 What is involved in catching C++ exceptions? Was this the 
 hard part of the whole
 thing?
DMD doesn't catch them yet. But C++ on Linux throws them in Dwarf format, so supporting that is the first step.
Useless work. Almost nobody will throw exceptions from C++ code to D code.
Facebook was doing it back in 2013 and had to deal with figuring out how to propagate them from the C++ code to the D code (which involved catching them on the C++ side and then wrapping them to hand over to D). So, folks have already been writing code that would benefit from being able to have C++ exceptions go from C++ code to D code. And since the D code can't control what a C++ function is going to throw, if we don't support C++ exceptions being caught in D, then a lot of extern(C++) functions will really need to be wrappers which catch any C++ exceptions that are thrown and then either handle them or hand them off to the D code somehow. And that's a lot more work than calling an existing C++ function for which you just write a signature for in D as extern(C++) and then call it normally, catching an exceptions that it throws just like you would in C++. So, yes. This work is valuable. Whether it's the best use of Walter's time out of all of the things he could be doing for D, I don't know, and that's a highly subjective debate. But I don't think that there's any question that this work is of real value and will really help folks who want to use D but need to integrate with existing C++ code - and that's a lot of the folks who would be looking to use D in a professional project. - Jonathan M Davis
Jan 05
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/5/2016 12:18 AM, Jonathan M Davis wrote:
  So, yes. This work is valuable. Whether it's the best use of Walter's time out
 of all of the things he could be doing for D, I don't know, and that's a highly
 subjective debate. But I don't think that there's any question that this work
is
 of real value and will really help folks who want to use D but need to
integrate
 with existing C++ code - and that's a lot of the folks who would be looking to
 use D in a professional project.
Andrei and I believe that directly connecting D to C++ is critical for D's future. Catching C++ exceptions is a key component of that. This feature has been on the table for a year now, and it has become clear that either I do it or it never happens. (Making it work right requires in depth understanding of the other mechanisms for EH that dmd uses, how the global optimizer works, how the code generator works, how the dwarf support works, how code is converted from ASTs to the back end notation, etc. That pretty much just leaves me.)
Jan 05
prev sibling next sibling parent reply wobbles <grogan.colin gmail.com> writes:
On Tuesday, 5 January 2016 at 01:39:51 UTC, Temtaime wrote:
 On Sunday, 3 January 2016 at 02:05:38 UTC, Walter Bright wrote:
 On 1/2/2016 4:17 PM, Jack Stouffer wrote:
 What is involved in catching C++ exceptions? Was this the 
 hard part of the whole
 thing?
DMD doesn't catch them yet. But C++ on Linux throws them in Dwarf format, so supporting that is the first step.
Useless work. Almost nobody will throw exceptions from C++ code to D code. Same old same old : Walter could fix regressions, but instead he found a new nice useless toy to play, and after that, it will be a cause of new regressions. That's why D is always dead in the water.
That's a bit harsh! Getting D to play nice with C++ is, I feel at least, one of the most important pieces of work to getting more D adoption. The vast amount of C++ libs out there that will be usable in the D sphere is immense (think Game engines!)
Jan 05
parent reply welkam <wwwelkam gmail.com> writes:
People who pay 0$ should not dictate what Walther should be doing.

I guess D will have best interoperability with c++ out of all 
languages.
Jan 05
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 5 January 2016 at 11:13:30 UTC, welkam wrote:
 People who pay 0$ should not dictate what Walther should be 
 doing.
I agree. What should be questioned is the viability of the strategy. 1. The core of game engine libraries don't use exceptions... So the exception handling focus is misguided. 2. Modern performant C++ libraries use templating through and through... D has not strategy for interfacing with these. How are you going to solve that with D? D's C++ support will be obsolete before it is finished. Meaning: it only make sense if you bind to your own C++ libraries or legacy C++ code.
 I guess D will have best interoperability with c++ out of all 
 languages.
Nope. Objective-C++ has full C++ support.
Jan 05
next sibling parent reply welkam <wwwelkam gmail.com> writes:
On Tuesday, 5 January 2016 at 11:21:48 UTC, Ola Fosheim Grøstad 
wrote:
 1. The core of game engine libraries don't use exceptions... So 
 the exception handling focus is misguided.

 2. Modern performant C++ libraries use templating through and 
 through... D has not strategy for interfacing with these.

 How are you going to solve that with D? D's C++ support will be 
 obsolete before it is finished.
I dont think there are plans for full C++ interoperability but some interop is better than none. People wont be rewriting millions of c++ code to D so interop is must, but supporting full c++ 14 spec is just too much to ask. If you cant modify c++ library and it is using templates then you`ll have to stick to c++.
 Nope. Objective-C++ has full C++ support.
first time hearing about it
Jan 05
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 5 January 2016 at 12:51:11 UTC, welkam wrote:
 Nope. Objective-C++ has full C++ support.
first time hearing about it
You can just rename an Objective-C or C++ file to ".mm" and you get an Objetive-C++ file. So if I have some files in Objective-C where I need interop with C++ I rename it to ".mm" and can include C++ headers directly. Or the other way, if I want to add Objective-C interfacing to C++ code. I assume I can use it for interfacing indirectly with Swift on Linux as well?? So, for me Swift/Objective-C++/C++/C currently looks more attractive than D2/C++ because I _should_ be able to get 100% C++14/17 support by having an Objective-C++ binding layer below Swift. (might not make sense for people that don't know Objective-C)
Jan 05
parent reply Jacob Carlborg <doob me.com> writes:
On 2016-01-05 14:30, Ola Fosheim Grøstad wrote:

 I assume I can use it for interfacing indirectly with Swift on Linux as
 well??
It's not possible to interface Swift and C++ directly. One needs to go though Objective-C++. There's a tool that can automatically generate bindings [1]. I have no idea how well that works. [1] https://github.com/sandym/swiftpp -- /Jacob Carlborg
Jan 05
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 5 January 2016 at 13:45:53 UTC, Jacob Carlborg wrote:
 On 2016-01-05 14:30, Ola Fosheim Grøstad wrote:

 I assume I can use it for interfacing indirectly with Swift on 
 Linux as
 well??
It's not possible to interface Swift and C++ directly. One needs to go though Objective-C++.
Yes, which is why I wrote "indirectly". ;-) But does it work for Swift on Linux? Is Objective-C++ and Swift compatible on Linux yet?
 There's a tool that can automatically generate bindings [1]. I 
 have no idea how well that works.

 [1] https://github.com/sandym/swiftpp
Thanks for the reference!
Jan 05
parent reply Jacob Carlborg <doob me.com> writes:
On 2016-01-05 14:49, Ola Fosheim Grøstad wrote:

 Yes, which is why I wrote "indirectly". ;-)
Ah, I missed that.
 But does it work for Swift
 on Linux? Is Objective-C++ and Swift compatible on Linux yet?
Hmm. From this blog post [1]: "Swift on Linux does not depend on the Objective-C runtime nor includes it" I'm guessing that Swift is compatible with Apple's Objective-C runtime, which is not the same as the GNUStep Objective-C runtime. On the other hand, I'm guessing it's possible to create a C bridge as well. [1] https://swift.org/blog/swift-linux-port/ -- /Jacob Carlborg
Jan 05
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 5 January 2016 at 15:40:40 UTC, Jacob Carlborg wrote:
 "Swift on Linux does not depend on the Objective-C runtime nor 
 includes it"

 I'm guessing that Swift is compatible with Apple's Objective-C 
 runtime, which is not the same as the GNUStep Objective-C 
 runtime.
Thanks, that makes sense. I think ARC can be faster without the Objective-C dependency.
 On the other hand, I'm guessing it's possible to create a C 
 bridge as well.

 [1] https://swift.org/blog/swift-linux-port/
Yep. Linux is dominated by C so it makes perfect sense to focus on Swift + C and make it perform well.
Jan 05
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2016-01-05 12:21, Ola Fosheim Grøstad wrote:

 2. Modern performant C++ libraries use templating through and through...
 D has not strategy for interfacing with these.

 How are you going to solve that with D? D's C++ support will be obsolete
 before it is finished.
D can already interface with C++ templates, as long as they are instantiated on the C++ side already. Then it's only a matter of mangling. -- /Jacob Carlborg
Jan 05
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/5/2016 3:21 AM, Ola Fosheim Grøstad wrote:
 Nope. Objective-C++ has full C++ support.
It's the other way around. O-C++ is a C++ compiler that supports O-C extensions. This is amply illustrated by Swift's total lack of C++ interoperability.
Jan 05
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 5 January 2016 at 16:10:38 UTC, Walter Bright wrote:
 On 1/5/2016 3:21 AM, Ola Fosheim Grøstad wrote:
 Nope. Objective-C++ has full C++ support.
It's the other way around. O-C++ is a C++ compiler that supports O-C extensions.
The difference is marginal. C++ on clang support C99 extensions to C++, like VLA (which I use quite frequently).
 This is amply illustrated by Swift's total lack of C++ 
 interoperability.
Actually, I think that is completely unrelated. Swift is a separate language that has been designed to work well with Cocoa rather than plain C IMO. Swift has a Objective-C/C++ compatible runtime, and _bridging_ to CoreFoundation (Apple's C allocated objects) just like Objective-C/C++. For non-CoreFoundation objects the situation is more troubled AFAIK. So to have good interfacing with Apple tech, you need Foundation or CoreFoundation objects... Not C++, C or D objects... I rarely deal with bridging, did I get this right?
Jan 05
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
An example from 
http://www.sitepoint.com/using-legacy-c-apis-swift/:

Calling the C function "void takesAnObject(void *theObject);" 
from Swift:

var test = 42
withUnsafePointer(&test, { (ptr: UnsafePointer<Int>) -> Void in
     var voidPtr: UnsafePointer<Void> = unsafeBitCast(ptr, 
UnsafePointer<Void>.self)
     takesAnObject(voidPtr)
})


Maybe it can be done better, but I think it is rather obvious 
that if interfacing looks like that, one doesn't loose much from 
implementing the app using Objective-C++ and Swift without 
bridging much between C++ and Swift.
Jan 05
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/5/2016 10:45 AM, Ola Fosheim Grøstad wrote:
 Calling the C function "void takesAnObject(void *theObject);" from Swift:
Interfacing with C doesn't mean jack when someone needs to interface with C++. D interfaced seamlessly with C from day 1.
Jan 05
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 5 January 2016 at 18:52:38 UTC, Walter Bright wrote:
 Interfacing with C doesn't mean jack when someone needs to 
 interface with C++. D interfaced seamlessly with C from day 1.
Yes, but if you want ARC or high performance GC you have to pay a price when crossing boundaries. Objective-C/C++ provides easy interfacing with C/C++... CoreFoundation provides easy bridging with Objective-C/Swift. Foundation provides seamless interfacing.
Jan 05
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/5/2016 10:57 AM, Ola Fosheim Grøstad wrote:
 CoreFoundation provides easy bridging with Objective-C/Swift.
CF is an interface to C, not C++, and it uses wrappers and such, not direct APIs. It also has COM-like support - D also supported COM since Day 1. That isn't remotely good enough to be called an interface to C++.
Jan 05
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 5 January 2016 at 21:33:07 UTC, Walter Bright wrote:
 On 1/5/2016 10:57 AM, Ola Fosheim Grøstad wrote:
 CoreFoundation provides easy bridging with Objective-C/Swift.
CF is an interface to C, not C++, and it uses wrappers and such, not direct APIs. It also has COM-like support - D also supported COM since Day 1. That isn't remotely good enough to be called an interface to C++.
I think I wasn't clear in what I wrote. CoreFoundation is implemented in C, but CF objects aren't really an interface to C, but memory objects that (may) provide a toll free bridge to NSObject ARC protocols. Thus supports ARC by recasting a pointer rather than wrapping or conversion. My point was more that in order to interface well with Swift I should generate objects that are toll free castable to ARC objects when I allocate. But I don't want that in my C++ code anyway, so therefore I might as well have a Objective-C++ layer between Swift and C++ on iOS. I don't want lots of raw C malloc or C++ objects on the Swift side... As Jacob pointed out, that does not work on Linux, but I am ok with C interfaces to C++ code on Linux. iOS is different since so many OS calls _requires_ Objective-C function calls, so on iOS you often need to mix Objective-C and C++ (or whatever language you use).
Jan 05
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/5/2016 1:48 PM, Ola Fosheim Grøstad wrote:
 I think I wasn't clear in what I wrote.
At the moment I'm only interested in directly interfacing D to C++, not C (which D already does very well) or ARC (a totally different subject).
Jan 05
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 6 January 2016 at 00:08:35 UTC, Walter Bright wrote:
 On 1/5/2016 1:48 PM, Ola Fosheim Grøstad wrote:
 I think I wasn't clear in what I wrote.
At the moment I'm only interested in directly interfacing D to C++, not C (which D already does very well) or ARC (a totally different subject).
The topic someone in this subthread raised was whether other comparable languages have better C++ support than D or not. And my answer to that is that Objective-C++ and Swift over Objective-C++ has 100% support for C++. That's the discussion you entered.
Jan 05
prev sibling next sibling parent watcher <xxx aol.com> writes:
On Tuesday, 5 January 2016 at 01:39:51 UTC, Temtaime wrote:
 On Sunday, 3 January 2016 at 02:05:38 UTC, Walter Bright wrote:
 On 1/2/2016 4:17 PM, Jack Stouffer wrote:
 What is involved in catching C++ exceptions? Was this the 
 hard part of the whole
 thing?
DMD doesn't catch them yet. But C++ on Linux throws them in Dwarf format, so supporting that is the first step.
Useless work. Almost nobody will throw exceptions from C++ code to D code. Same old same old : Walter could fix regressions, but instead he found a new nice useless toy to play, and after that, it will be a cause of new regressions. That's why D is always dead in the water.
+1000
Jan 05
prev sibling parent Jason Jeffory <JasonJeffory doodle.com> writes:
On Tuesday, 5 January 2016 at 01:39:51 UTC, Temtaime wrote:
 On Sunday, 3 January 2016 at 02:05:38 UTC, Walter Bright wrote:
 On 1/2/2016 4:17 PM, Jack Stouffer wrote:
 What is involved in catching C++ exceptions? Was this the 
 hard part of the whole
 thing?
DMD doesn't catch them yet. But C++ on Linux throws them in Dwarf format, so supporting that is the first step.
Useless work. Almost nobody will throw exceptions from C++ code to D code. Same old same old : Walter could fix regressions, but instead he found a new nice useless toy to play, and after that, it will be a cause of new regressions. That's why D is always dead in the water.
Seriously? Walter has every right to work on what he wants, regardless. D is his child, not yours! How bout you contribute to the problems you see and let him contribute in his way and the world would be a better place? At least is he is working on what he thinks is correct! Lazy people that just bitch and complain about what other people do is the downfall of humanity.... so how does it feel knowing that you are contributing to the death and decay of the greatest species this planet has known(possibly universe)? Grow up!
Jan 05
prev sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 3 Jan 2016 1:20 am, "Jack Stouffer via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:
 On Saturday, 2 January 2016 at 21:16:38 UTC, Walter Bright wrote:
 What I've been working on for the last month or so.

 https://github.com/D-Programming-Language/dmd/pull/5324

 For Linux 64 anyway. Anyone who wants to do PRs to extend it to Linux
32, OSX and FreeBSD, feel free! Unfortunately, this is of no help with Win64, which uses its own unique system. DMD for Win32 already can catch C++ exceptions, but Win32 is a dead platform.
 This is an enabling technology that will confer on D the ability to
catch C++ exceptions, which is key to interaction with native C++ libraries.
 Next up: actually catching C++ exceptions!

 Thanks to everyone who helped out with this.
Congrats! What is involved in catching C++ exceptions? Was this the hard part of
the whole thing? Catching from any foreign language that interacts with the same EH interface should be easy. Just bear in mind that each language may put the thrown object proper in a different place.
Jan 05
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/5/2016 1:17 AM, Iain Buclaw via Digitalmars-d wrote:
 Catching from any foreign language that interacts with the same EH interface
 should be easy.  Just bear in mind that each language may put the thrown object
 proper in a different place.
Doing unwinding in D frames when foreign exceptions are in-flight is easy, because no knowledge of those FEs is required. Catching them, however, requires detailed knowledge of exactly how they work. This is not so easy. Catching C++ exceptions in D code will require some careful study and work, and that work will not be transferable to other FEs. But since there seems to be 0 demand for catching other FEs, or even interfacing D to other languages, this shouldn't be a problem.
Jan 05
next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 5 January 2016 at 17:24, Walter Bright via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 On 1/5/2016 1:17 AM, Iain Buclaw via Digitalmars-d wrote:

 Catching from any foreign language that interacts with the same EH
 interface
 should be easy.  Just bear in mind that each language may put the thrown
 object
 proper in a different place.
Doing unwinding in D frames when foreign exceptions are in-flight is easy, because no knowledge of those FEs is required. Catching them, however, requires detailed knowledge of exactly how they work. This is not so easy. Catching C++ exceptions in D code will require some careful study and work, and that work will not be transferable to other FEs. But since there seems to be 0 demand for catching other FEs, or even interfacing D to other languages, this shouldn't be a problem.
I gave a very abridged example here: http://forum.dlang.org/post/mailman.2091.1447287382.22025.digitalmars-d puremagic.com Referenced unwind-cxx.h is found in a github mirror: https://github.com/gcc-mirror/gcc/blob/1e9147dd7b41b6e32c25501b50df73e74b75387f/libstdc%2B%2B-v3/libsupc%2B%2B/unwind-cxx.h#L58-L98
Jan 05
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2016-01-05 17:24, Walter Bright wrote:

 Doing unwinding in D frames when foreign exceptions are in-flight is
 easy, because no knowledge of those FEs is required.

 Catching them, however, requires detailed knowledge of exactly how they
 work. This is not so easy. Catching C++ exceptions in D code will
 require some careful study and work, and that work will not be
 transferable to other FEs.

 But since there seems to be 0 demand for catching other FEs, or even
 interfacing D to other languages, this shouldn't be a problem.
Catching Objective-C exceptions might be interesting. If if catching C++ exceptions work, it should be trivial to add support for catching Objective-C exceptions as well. -- /Jacob Carlborg
Jan 05
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
So, we have ELF binaries and DWARF exceptions. Are we going to 
get something related to orcs or goblins next? ;)

- Jonathan M Davis
Jan 02
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/2/2016 5:51 PM, Jonathan M Davis wrote:
 So, we have ELF binaries and DWARF exceptions. Are we going to get something
 related to orcs or goblins next? ;)
Naw, but I am secretly working on the Eye of Sauron.
Jan 02
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, 3 January 2016 at 02:04:40 UTC, Walter Bright wrote:
 On 1/2/2016 5:51 PM, Jonathan M Davis wrote:
 So, we have ELF binaries and DWARF exceptions. Are we going to 
 get something
 related to orcs or goblins next? ;)
Naw, but I am secretly working on the Eye of Sauron.
LOL. And wouldn't _that_ show how powerful D is. ;) - Jonathan M Davis
Jan 02
prev sibling parent blm768 <blm768 gmail.com> writes:
On Sunday, 3 January 2016 at 01:51:35 UTC, Jonathan M Davis wrote:
 So, we have ELF binaries and DWARF exceptions. Are we going to 
 get something related to orcs or goblins next? ;)

 - Jonathan M Davis
I don't know about that, but with better C++ interop, it might be easier to bind to OGRE. (See http://www.ogre3d.org/)
Jan 02
prev sibling next sibling parent reply Dan Olson <gorox comcast.net> writes:
Walter Bright <newshound2 digitalmars.com> writes:

 What I've been working on for the last month or so.

 https://github.com/D-Programming-Language/dmd/pull/5324

 For Linux 64 anyway. Anyone who wants to do PRs to extend it to Linux
 32, OSX and FreeBSD, feel free! Unfortunately, this is of no help with
 Win64, which uses its own unique system. DMD for Win32 already can
 catch C++ exceptions, but Win32 is a dead platform.

 This is an enabling technology that will confer on D the ability to
 catch C++ exceptions, which is key to interaction with native C++
 libraries.

 Next up: actually catching C++ exceptions!

 Thanks to everyone who helped out with this.
Very cool. Is it conceivable that DMD, GDC, and LDC might one day share common support code in druntime (personality, etc)? Could be many benefits like a larger test population. -- Dan
Jan 04
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/4/2016 4:18 PM, Dan Olson wrote:
 Very cool.  Is it conceivable that DMD, GDC, and LDC might one day share
 common support code in druntime (personality, etc)?  Could be many
 benefits like a larger test population.
Probably not the personality routine, though that won't matter.
Jan 04
prev sibling parent Ilya <ilyayaroshenko gmail.com> writes:
On Saturday, 2 January 2016 at 21:16:38 UTC, Walter Bright wrote:
 What I've been working on for the last month or so.

 https://github.com/D-Programming-Language/dmd/pull/5324

 For Linux 64 anyway. Anyone who wants to do PRs to extend it to 
 Linux 32, OSX and FreeBSD, feel free! Unfortunately, this is of 
 no help with Win64, which uses its own unique system. DMD for 
 Win32 already can catch C++ exceptions, but Win32 is a dead 
 platform.

 This is an enabling technology that will confer on D the 
 ability to catch C++ exceptions, which is key to interaction 
 with native C++ libraries.

 Next up: actually catching C++ exceptions!

 Thanks to everyone who helped out with this.
Is this hack required for dmd 2.070 to get stack-trace on Linux 64? ---------- import etc.linux.memoryerror; static if (is(typeof(registerMemoryErrorHandler))) registerMemoryErrorHandler(); ---------- -- Ilya
Jan 04