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

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

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.

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!)

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.

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.

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

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)

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

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