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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016
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 2016