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

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!

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

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!

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

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.

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.

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

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?

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.