So what exactly is coming with extended C++ support?

[Szymon Gatner via Digitalmars-d]

Hi,

recently there is much talk about extending C++ interop in D but
it is unclear to me what that means. Functions and virtual class
methods are already callable. What else is planned in the near
future? Exceptions? Support for C++ templates? (that seems
difficult no?).

Is VS support planned (I think I saw Andrei only asking about GCC
support for exceptions/stack unwining)? Atm it does not really
work (even building x64 exe with D lib linked).

From the PoV of small game developer relying its livelihood on
C++ I must say that this is great thing. If I had better support
for 2 things now: C++ interop so we could just start writing new
code in D and ARM/iOS then we would just move immediately.

In short, I am very happy (but only if you remember about VC
users!) to hear about this direction. Some people here seem to
think that this is not relevant effort but clearly they don't
have existing C++ code to maintain and deal with.

[Jacob Carlborg via Digitalmars-d]

Hi,
recently there is much talk about extending C++ interop in D but it is
unclear to me what that means. Functions and virtual class methods are
already callable. What else is planned in the near future? Exceptions?
Support for C++ templates? (that seems difficult no?).

Using templates are already supported. Note, they need to instantiated
on the C++ side.

Is VS support planned (I think I saw Andrei only asking about GCC
support for exceptions/stack unwining)? Atm it does not really work
(even building x64 exe with D lib linked).
From the PoV of small game developer relying its livelihood on C++ I
must say that this is great thing. If I had better support for 2 things
now: C++ interop so we could just start writing new code in D and
ARM/iOS then we would just move immediately.

Don't know if this is what you're looking for but this pull request [1]
adds support for extern(Objective-C).

[1] https://github.com/D-Programming-Language/dmd/pull/3987

[Szymon Gatner via Digitalmars-d]

On Monday, 29 September 2014 at 14:36:10 UTC, Jacob Carlborg

Post by Jacob Carlborg via Digitalmars-d

Post by Szymon Gatner via Digitalmars-d
Hi,
recently there is much talk about extending C++ interop in D
but it is
unclear to me what that means. Functions and virtual class
methods are
already callable. What else is planned in the near future?
Exceptions?
Support for C++ templates? (that seems difficult no?).

Using templates are already supported. Note, they need to
instantiated on the C++ side.

Ah, cool, but I still have no clue what to expect from ongoing
discussion on C++ interop. Does anyone know?

Post by Jacob Carlborg via Digitalmars-d
[1] https://github.com/D-Programming-Language/dmd/pull/3987

Yup, I saw it and this makes me very happy. iOS run-time is still
an issue tho.

[bachmeier via Digitalmars-d]

Post by Szymon Gatner via Digitalmars-d
From the PoV of small game developer relying its livelihood on
C++ I must say that this is great thing. If I had better
support for 2 things now: C++ interop so we could just start
writing new code in D and ARM/iOS then we would just move
immediately.

Is that all it would take? Do you also need a GC-free standard
library, which seems to be the need of all the others saying "do
this and I'll switch from C++"? Are the tools good enough?

I don't think anyone is saying C++ interop is unimportant. There
are a lot of us already using the language and we don't think C++
interop is the only thing that has value. More important IMO
would be releasing a compiler without a bunch of regressions. D
is a lot more than a C++ replacement for Facebook or video game
developers.

[Wyatt via Digitalmars-d]

Post by bachmeier via Digitalmars-d
Is that all it would take? Do you also need a GC-free standard
library, which seems to be the need of all the others saying
"do this and I'll switch from C++"? Are the tools good enough?

No relation to OP, but I can tell you it is unbelievably more
important. For the most part, deficiencies in Phobos can
reasonably be worked around or improved. The body of useful
libraries written in C++ can't.

Post by bachmeier via Digitalmars-d
I don't think anyone is saying C++ interop is unimportant.
There are a lot of us already using the language and we don't
think C++ interop is the only thing that has value.

That's true, but how many wheels are you really willing to
reinvent? And how many man years are you willing to spend doing
it?

-Wyatt

[Szymon Gatner via Digitalmars-d]

On Monday, 29 September 2014 at 10:00:27 UTC, Szymon Gatner
Is that all it would take? Do you also need a GC-free standard
library, which seems to be the need of all the others saying
"do this and I'll switch from C++"? Are the tools good enough?

Considered how many games (and I don't mean indie anymore, but
for example Blizzard's Heartstone) are now created in Unity which
uses not only GC but runs in Mono I am very skeptical of anybody
claiming GC is a no-go for games. - Especially- that native
executable is being built in case of D.

I realize AAA's have have their reasons against GC i but in that
case one should probably just get UE4 license anyway.

Tooling is acceptable for me tbh. Coming from C++ I don't have
high expectations anyway. The only good debugger (for C++) is
VC++ and so far I'v had surprisingly good experience with VisualD
and mixed C++/D application. Stepping into function (between
language boundries!) just works. Viewing variable values works
properly too whether I in on *.cpp or .d file atm. Overall, can't
complain too much especially I am getting all those goodies for
free ;)

Anyway, I accept that I would be an early adopter and I am OK
with some cons that come with it as I see more gains overall.

Btw, I think D is THE language to implement gameplay. Compilation
times make it on par with scripting languages and since it
becomes compiled there are no JIT restrictions on iOS for
example. In our case AI will get rewritten from C++/Lua to D as
soon as it is practical which s not just yet unfortunately.

I don't think anyone is saying C++ interop is unimportant.
There are a lot of us already using the language and we don't
think C++ interop is the only thing that has value. More
important IMO would be releasing a compiler without a bunch of
regressions. D is a lot more than a C++ replacement for
Facebook or video game developers.

Don't get me wrong, I too want all those issue resolved, just
saying for myself that (lack) of those features blocks us from
adopting at all. And after we're on board I suspect I will join
some other unhappy camp :P But for now we can't even get there.

[Chris via Digitalmars-d]

On Tuesday, 30 September 2014 at 08:48:19 UTC, Szymon Gatner

Post by Szymon Gatner via Digitalmars-d

On Monday, 29 September 2014 at 10:00:27 UTC, Szymon Gatner
Is that all it would take? Do you also need a GC-free standard
library, which seems to be the need of all the others saying
"do this and I'll switch from C++"? Are the tools good enough?

Considered how many games (and I don't mean indie anymore, but
for example Blizzard's Heartstone) are now created in Unity
which uses not only GC but runs in Mono I am very skeptical of
anybody claiming GC is a no-go for games. - Especially- that
native executable is being built in case of D.

Very interesting.

Post by Szymon Gatner via Digitalmars-d
I realize AAA's have have their reasons against GC i but in
that case one should probably just get UE4 license anyway.
Tooling is acceptable for me tbh. Coming from C++ I don't have
high expectations anyway. The only good debugger (for C++) is
VC++ and so far I'v had surprisingly good experience with
VisualD and mixed C++/D application. Stepping into function
(between language boundries!) just works. Viewing variable
values works properly too whether I in on *.cpp or .d file atm.
Overall, can't complain too much especially I am getting all
those goodies for free ;)
Anyway, I accept that I would be an early adopter and I am OK
with some cons that come with it as I see more gains overall.
Btw, I think D is THE language to implement gameplay.
Compilation times make it on par with scripting languages and
since it becomes compiled there are no JIT restrictions on iOS
for example. In our case AI will get rewritten from C++/Lua to
D as soon as it is practical which s not just yet unfortunately.

It's good to hear that. Maybe you could write a short article
about that once you've moved to D. "Porting games to D" or
something like that. With D you can develop fast due to short
compilation times, that's important for testing and prototyping.

iOS/ARM are very important. What's the latest state of affairs? I
know some progress has been made but it has been off my radar for
a month or two now.

Post by Szymon Gatner via Digitalmars-d

I don't think anyone is saying C++ interop is unimportant.
There are a lot of us already using the language and we don't
think C++ interop is the only thing that has value. More
important IMO would be releasing a compiler without a bunch of
regressions. D is a lot more than a C++ replacement for
Facebook or video game developers.

Don't get me wrong, I too want all those issue resolved, just
saying for myself that (lack) of those features blocks us from
adopting at all. And after we're on board I suspect I will join
some other unhappy camp :P But for now we can't even get there.

[Szymon Gatner via Digitalmars-d]

Post by Chris via Digitalmars-d
It's good to hear that. Maybe you could write a short article
about that once you've moved to D. "Porting games to D" or
something like that. With D you can develop fast due to short
compilation times, that's important for testing and prototyping.

I actually was planning on something like that. I am still
thinking about writing on automatic binding generation between D
and Lua using D's compile-time reflection. Add a UDA to a
function, class, method a voila! You can call it from Lua. Magic!

[John Colvin via Digitalmars-d]

On Tuesday, 30 September 2014 at 10:06:47 UTC, Szymon Gatner

Post by Szymon Gatner via Digitalmars-d

Post by Chris via Digitalmars-d
It's good to hear that. Maybe you could write a short article
about that once you've moved to D. "Porting games to D" or
something like that. With D you can develop fast due to short
compilation times, that's important for testing and
prototyping.

I actually was planning on something like that. I am still
thinking about writing on automatic binding generation between
D and Lua using D's compile-time reflection. Add a UDA to a
function, class, method a voila! You can call it from Lua.
Magic!

I presume you're familiar with http://code.dlang.org/packages/luad

[Szymon Gatner via Digitalmars-d]

Post by John Colvin via Digitalmars-d
On Tuesday, 30 September 2014 at 10:06:47 UTC, Szymon Gatner

Post by Szymon Gatner via Digitalmars-d

Post by Chris via Digitalmars-d
It's good to hear that. Maybe you could write a short article
about that once you've moved to D. "Porting games to D" or
something like that. With D you can develop fast due to short
compilation times, that's important for testing and
prototyping.

I actually was planning on something like that. I am still
thinking about writing on automatic binding generation between
D and Lua using D's compile-time reflection. Add a UDA to a
function, class, method a voila! You can call it from Lua.
Magic!

I presume you're familiar with
http://code.dlang.org/packages/luad

I am, but it is incredible how much of the binding-code can be
generated with just few lines of D.

Please, does anybody know anything about my original question? :P

[Chris via Digitalmars-d]

On Tuesday, 30 September 2014 at 10:06:47 UTC, Szymon Gatner

Post by Szymon Gatner via Digitalmars-d

Post by Chris via Digitalmars-d
It's good to hear that. Maybe you could write a short article
about that once you've moved to D. "Porting games to D" or
something like that. With D you can develop fast due to short
compilation times, that's important for testing and
prototyping.

I actually was planning on something like that. I am still
thinking about writing on automatic binding generation between
D and Lua using D's compile-time reflection. Add a UDA to a
function, class, method a voila! You can call it from Lua.
Magic!

Great. I'm interested in Lua-D interaction. Would you share it on
GitHub once it's done?

Have you had a look at DerelictLua:
https://github.com/DerelictOrg/DerelictLua

[Szymon Gatner via Digitalmars-d]

Post by Chris via Digitalmars-d
Great. I'm interested in Lua-D interaction. Would you share it
on GitHub once it's done?
https://github.com/DerelictOrg/DerelictLua

I was thinking about maybe just posting snippets on the blog but
GitHub should be doable. I am not much of a blogger tho...
Anyway, I would be nothing new to D programmer but I think it
would be quite interesting for C++ programmer dealing with
variadic marcos and boost.mpl for (the half of) similar result.

[Szymon Gatner via Digitalmars-d]

Post by Chris via Digitalmars-d
https://github.com/DerelictOrg/DerelictLua

Forgot to reply to 2nd part: yes I looked at it and in fact I
tried my code using it.

[Szymon Gatner via Digitalmars-d]

Post by Chris via Digitalmars-d
https://github.com/DerelictOrg/DerelictLua

Forgot to reply to 2nd part: yes I looked at it and in fact I
tried my code using it.

[Chris via Digitalmars-d]

On Tuesday, 30 September 2014 at 10:06:47 UTC, Szymon Gatner

Post by Szymon Gatner via Digitalmars-d

Post by Chris via Digitalmars-d
It's good to hear that. Maybe you could write a short article
about that once you've moved to D. "Porting games to D" or
something like that. With D you can develop fast due to short
compilation times, that's important for testing and
prototyping.

I actually was planning on something like that. I am still
thinking about writing on automatic binding generation between
D and Lua using D's compile-time reflection. Add a UDA to a
function, class, method a voila! You can call it from Lua.
Magic!

Great. I'm interested in Lua-D interaction. Would you share it on
GitHub once it's done?

Have you had a look at DerelictLua:
https://github.com/DerelictOrg/DerelictLua

[Dan Olson via Digitalmars-d]

iOS/ARM are very important. What's the latest state of affairs? I know
some progress has been made but it has been off my radar for a month
or two now.

The iOS project with LDC has been idle during the windsurfing season
:-). Days are geting shorter so I plan to resume work on it.

For a start, it needs to be updated to latest LDC version. About 10
phobos unit tests were not passing back in April and most of these were
due to floating pointing differences between host (x64) and target
(arm).

[Szymon Gatner via Digitalmars-d]

Post by Dan Olson via Digitalmars-d

Post by Chris via Digitalmars-d
iOS/ARM are very important. What's the latest state of
affairs? I know
some progress has been made but it has been off my radar for a month
or two now.

The iOS project with LDC has been idle during the windsurfing
season
:-). Days are geting shorter so I plan to resume work on it.
For a start, it needs to be updated to latest LDC version.
About 10
phobos unit tests were not passing back in April and most of
these were
due to floating pointing differences between host (x64) and
target
(arm).

That is good to hear indeed. In your estimate: how much longer
until D is usable on iOS?

[Dan Olson via Digitalmars-d]

That is good to hear indeed. In your estimate: how much longer until D
is usable on iOS?

Depends on your definition of "usable" Szymon.

If it is just me working on it, I think a standalone LDC cross compiler
to 32-bit arm devices with druntime/phobos can be ready in a few months.
Maybe early first quarter 2015. By standalone I mean just the LDC
toolchain.

This would allow a D library to be embedded in an otherwise Objective-C
(or maybe Swift?) iOS app.

How about bindings for APIs in the iPhone SDK? I think folks can build
those as needed with help from Jacob's dstep tool. It would be nice to
have a repository for these bindings somewhere though.

It would be cool if by Feb/Mar 2015 a demo app could be submited to the
App Store, just to test acceptance. I think Walter's D version of
"Empire", but with the original ASCII character graphics, would be a fun
choice ;-)

I really don't know how to predict the timing for the following:

Objective-C interop (DIP 43). Without it, it will be hard to go all out
"D" in an iOS app. I have not been following the pull request and don't
have any idea when it might bubble into LDC via DMD, but not anytime
soon I would guess. Would it be good to merge it onto a LDC+iOS git
branch? Just as a temporary proof of concept?

Then there are all the tool related things that might hinder D use on
iOS. Things such as no source level debugging, lack of D/Xcode
integration.

Oh, and compiling to arm64 for newer devices.

[Szymon Gatner via Digitalmars-d]

Post by Dan Olson via Digitalmars-d

That is good to hear indeed. In your estimate: how much longer until D
is usable on iOS?

Depends on your definition of "usable" Szymon.
This would allow a D library to be embedded in an otherwise
Objective-C
(or maybe Swift?) iOS app.

That is my definition :)

I would use static D library in C++ iOS application.

Post by Dan Olson via Digitalmars-d
How about bindings for APIs in the iPhone SDK? I think folks
can build
those as needed with help from Jacob's dstep tool. It would be nice to
have a repository for these bindings somewhere though.

Would be nice but much less important for me.

Post by Dan Olson via Digitalmars-d
It would be cool if by Feb/Mar 2015 a demo app could be
submited to the
App Store, just to test acceptance.

I would gladly do that

Post by Dan Olson via Digitalmars-d
Then there are all the tool related things that might hinder D
use on
iOS. Things such as no source level debugging, lack of D/Xcode
integration.

Right

Post by Dan Olson via Digitalmars-d
Oh, and compiling to arm64 for newer devices.

Knowing Apple that will be mandatory for new apps soon.

Thanks for all your work!

[Jacob Carlborg via Digitalmars-d]

Post by Dan Olson via Digitalmars-d
This would allow a D library to be embedded in an otherwise Objective-C
(or maybe Swift?) iOS app.

Sure, as long as it's using an Objective-C compatible API.

Post by Dan Olson via Digitalmars-d
How about bindings for APIs in the iPhone SDK? I think folks can build
those as needed with help from Jacob's dstep tool. It would be nice to
have a repository for these bindings somewhere though.

I will create Dub packages when I need some framework, unless someone
else beats me to it.

Post by Dan Olson via Digitalmars-d
Objective-C interop (DIP 43). Without it, it will be hard to go all out
"D" in an iOS app. I have not been following the pull request and don't
have any idea when it might bubble into LDC via DMD, but not anytime
soon I would guess.

It needs some refactoring, which I've already started.

Post by Dan Olson via Digitalmars-d
Then there are all the tool related things that might hinder D use on
iOS. Things such as no source level debugging

I think I have used Xcode to debug a D application.

Post by Dan Olson via Digitalmars-d
lack of D/Xcode integration.

Yeah, it will be far from as convenient as using Swift but I think it's
possible. Most tools Xcode uses: compiling, build nib files and so on
are command line tools. For example, TextMate is using Ninja as a build
system, completely without Xcode. It still uses nib files and other OS X
specific features.

[Dan Olson via Digitalmars-d]

Post by Jacob Carlborg via Digitalmars-d

Post by Dan Olson via Digitalmars-d
Then there are all the tool related things that might hinder D use on
iOS. Things such as no source level debugging

I think I have used Xcode to debug a D application.

Specifically here I mean LDC targeted to arm-ios. The linker complains
about the generated debug info and I end up stepping through D in arm
assembly.

[Johnathan via Digitalmars-d]

On Tuesday, 30 September 2014 at 08:48:19 UTC, Szymon Gatner

Post by Szymon Gatner via Digitalmars-d
I realize AAA's have have their reasons against GC i but in
that case one should probably just get UE4 license anyway.

UE4 uses a GC internally. The issue with using D's GC for games
is a matter of quality/adaptability.
Allocations in games should be rare (and after game startup,
should mostly be small objects, if there's any allocations at
all), so a GC for games would need minimal pauses and extremely
quick small allocations.

[Szymon Gatner via Digitalmars-d]

Post by Chris via Digitalmars-d
On Tuesday, 30 September 2014 at 08:48:19 UTC, Szymon Gatner

Post by Szymon Gatner via Digitalmars-d
I realize AAA's have have their reasons against GC i but in
that case one should probably just get UE4 license anyway.

UE4 uses a GC internally. The issue with using D's GC for games
is a matter of quality/adaptability.

True, but not in the sense that it is using GC-based language. It
is custom C++ solution tailored for the purpose.

Post by Chris via Digitalmars-d
Allocations in games should be rare (and after game startup,
should mostly be small objects, if there's any allocations at
all), so a GC for games would need minimal pauses and extremely
quick small allocations.

All true again, pre-allocation can fix lots of pause issues. And
simply not using GC in tight loops. While not the greatest fan of
Unity, it proved that GC (on top of of VM) is not a concern for
(I argue) most of gamedev. Minecraft was originally written in
Java for crying out loud yet it didn't stop it from becoming
gigantic success.

[po via Digitalmars-d]

Post by Szymon Gatner via Digitalmars-d
All true again, pre-allocation can fix lots of pause issues.
And simply not using GC in tight loops. While not the greatest
fan of Unity, it proved that GC (on top of of VM) is not a
concern for (I argue) most of gamedev. Minecraft was originally
written in Java for crying out loud yet it didn't stop it from
becoming gigantic success.

Unity the engine is written in C++. When you create a game using
Unity you are merely scripting the C++ engine using C#, no
different than the countless games that do the same using Lua.

[Paulo Pinto via Digitalmars-d]

Post by po via Digitalmars-d

Post by Szymon Gatner via Digitalmars-d
All true again, pre-allocation can fix lots of pause issues.
And simply not using GC in tight loops. While not the greatest
fan of Unity, it proved that GC (on top of of VM) is not a
concern for (I argue) most of gamedev. Minecraft was
originally written in Java for crying out loud yet it didn't
stop it from becoming gigantic success.

Unity the engine is written in C++. When you create a game
using Unity you are merely scripting the C++ engine using C#,
no different than the countless games that do the same using
Lua.

This will most likely change when they get their IL2CPP
production ready and start moving code from C++ to C#.

Or when Microsoft finishes the ongoing work on .NET Native.

--
Paulo

[po via Digitalmars-d]

Post by Paulo Pinto via Digitalmars-d
This will most likely change when they get their IL2CPP
production ready and start moving code from C++ to C#.
Or when Microsoft finishes the ongoing work on .NET Native.
--
Paulo

I'd not seen IL2CPP before, but from this link:

http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-in-unity/

It appears to act as a replacement for the mono VM, allowing for
AoT compilation of .Net IL into C++, so that they can benefit
from existing C++ compiler tech.

It doesn't mention anything about moving C++ into C#.
Even with IL2CPP, C# has fundamental design trade offs that make
it slower than C++(GC is just one of them), so it wouldn't make
much sense to port engine code to C# unless they wanted it to run
slower.

[via Digitalmars-d]

Post by po via Digitalmars-d
It doesn't mention anything about moving C++ into C#.
Even with IL2CPP, C# has fundamental design trade offs that
make it slower than C++(GC is just one of them), so it wouldn't
make much sense to port engine code to C# unless they wanted it
to run slower.

Yes, the info on CIL instruction set suggests that is a very
simple IR, which is an advantage if you want to prove safety or
write portable code, but that also means CIL will have a hard
time beating llvm. Some performance related decisions have to be
taken at a higher abstraction level than CIL.

[Araq via Digitalmars-d]

Post by po via Digitalmars-d
It doesn't mention anything about moving C++ into C#.
Even with IL2CPP, C# has fundamental design trade offs that
make it slower than C++(GC is just one of them), so it wouldn't
make much sense to port engine code to C# unless they wanted it
to run slower.

What are these fundamental design trade offs?

[Szymon Gatner via Digitalmars-d]

Post by Araq via Digitalmars-d

Post by po via Digitalmars-d
It doesn't mention anything about moving C++ into C#.
Even with IL2CPP, C# has fundamental design trade offs that
make it slower than C++(GC is just one of them), so it
wouldn't make much sense to port engine code to C# unless they
wanted it to run slower.

What are these fundamental design trade offs?

Guys I beg you, is there any chance I will get my answers? ;)

[via Digitalmars-d]

On Tuesday, 30 September 2014 at 14:28:49 UTC, Szymon Gatner

Post by Szymon Gatner via Digitalmars-d

Post by Araq via Digitalmars-d

Post by po via Digitalmars-d
It doesn't mention anything about moving C++ into C#.
Even with IL2CPP, C# has fundamental design trade offs that
make it slower than C++(GC is just one of them), so it
wouldn't make much sense to port engine code to C# unless
they wanted it to run slower.

What are these fundamental design trade offs?

http://en.wikipedia.org/wiki/List_of_CIL_instructions

Post by Szymon Gatner via Digitalmars-d
Guys I beg you, is there any chance I will get my answers? ;)

Nope :)

I don't think anyone know what extended C++ actually will look
like.

Some people say D is going to have std::* support, but that
would require someone to keep track of changes in all the c++
compilers D is supposed to support: Clang, G++, and VC++


Some people say they want full support for C++ exceptions, some
say it is too difficult


However, you don't need std::* or C++ exceptions for a game? Some
aspects of "extended C++ support" is going to be either wishful
thinking or non-portable, so you probably should try to avoid
depending on it. What are you missing?

[Szymon Gatner via Digitalmars-d]

On Tuesday, 30 September 2014 at 14:34:49 UTC, Ola Fosheim

Post by via Digitalmars-d

Post by Szymon Gatner via Digitalmars-d
Guys I beg you, is there any chance I will get my answers? ;)

Nope :)

I suspected so :P

Post by via Digitalmars-d
I don't think anyone know what extended C++ actually will look
like.

Great.

Post by via Digitalmars-d
Some people say D is going to have std::* support, but that
would require someone to keep track of changes in all the c++
compilers D is supposed to support: Clang, G++, and VC++


My thoughts too. Seems like maintenance hell.

Post by via Digitalmars-d
Some people say they want full support for C++ exceptions, some
say it is too difficult

However, you don't need std::* or C++ exceptions for a game?
Some aspects of "extended C++ support" is going to be either
wishful thinking or non-portable, so you probably should try to
avoid depending on it. What are you missing?

I use both std/boost and exceptions when makes sense - game is
not just rendering and number crunching after all.

Tbh what I -am missing- is proper run-time support for what is
already suppose to work (building x64 C++/D app crashes when
calling writeln() from D side). Win32 support is coming but I
expect similar problems (is nobody really mixing C++ and D using
VC++ atm?).

It would be great to be able to call non-virtual members of C++
classes from D but
I don't really need anything else from the language SPECS to
start things going - my question is out of pure curiosity.

That being said my biggest fear is that D2 will never be
finished... I am lurking on those forums for 2 years now, waiting
for the signal to start the transition but I need to be sure that
in few months everything I need and the code I write will work as
expected (and on iOS too). I am not seeing this unfortunately,
language is still being actively discussed on the most basic
level (allocators, ARC, auto-decoding of utf strings...). It
looks like Phobos might need to be rewritten entirely and soon. I
will not give up tho, if I must skip D for one more project
(which lasts year or two) then be it, hopefully I will be able to
use if for the nest one :(

[Ola Fosheim Grostad via Digitalmars-d]

On Tuesday, 30 September 2014 at 17:11:48 UTC, Szymon Gatner

Post by Szymon Gatner via Digitalmars-d
I use both std/boost and exceptions when makes sense - game is
not just rendering and number crunching after all.

I used some parts of boost c++0x std on ios a few years ago. I
guess it is no longer maintained, but maybe it is possible to use
the useful parts of a generic std library and match the memory
layout on the D side?

Post by Szymon Gatner via Digitalmars-d
calling writeln() from D side). Win32 support is coming but I
expect similar problems (is nobody really mixing C++ and D
using VC++ atm?).

Dunno.

Post by Szymon Gatner via Digitalmars-d
That being said my biggest fear is that D2 will never be
finished... I am lurking on those forums for 2 years now,
waiting for the signal to start the transition but I need to be
sure that in few months everything I need and the code I write
will work as expected (and on iOS too). I am not seeing this

Well, I looked at D1 eight years ago with the intent of using it
for game/world content on the server side. It was kind of nice,
but the compiler was basic. Then I decided to drop D1 and wait
for D2 when it was announced, and been tracking it ever since...
So yeah, impatient. I dont think there will be a game friendly D
version untill someone decides to cooperate on D--. Basically
cutting features and redesign for fast precise GC that minimize
cache load and that can run 60 times per sec without taking more
than 10% of the cpu.

I think it is doable for a given execution and memory model. Add
some constraints and performance will happen! :-)

Post by Szymon Gatner via Digitalmars-d
strings...). It looks like Phobos might need to be rewritten
entirely and soon. I will not give up tho, if I must skip D for
one more project (which lasts year or two) then be it,
hopefully I will be able to use if for the nest one :(

If all the people who want to use it for game content ( not
engine, but content ) cooperated and created c++ compatible
datatypes then maybe we could have something going within 6-12
months?

[via Digitalmars-d]

On Tuesday, 30 September 2014 at 19:47:32 UTC, Ola Fosheim

I dont think there will be a game friendly D version untill
someone decides to cooperate on D--. Basically cutting features
and redesign for fast precise GC that minimize cache load and
that can run 60 times per sec without taking more than 10% of
the cpu.
I think it is doable for a given execution and memory model.
Add some constraints and performance will happen! :-)

There's probably not much feature-wise that stands in the way of
a fast precise GC. Implicitly shared `immutable` is one example,
but other than that, I would say it's mostly unimplemented bits
and pieces (missing type information) and "wrong" decisions made
when designing the standard library.

[Paulo Pinto via Digitalmars-d]

Post by Szymon Gatner via Digitalmars-d

Post by Araq via Digitalmars-d

Post by po via Digitalmars-d
It doesn't mention anything about moving C++ into C#.
Even with IL2CPP, C# has fundamental design trade offs that make it
slower than C++(GC is just one of them), so it wouldn't make much
sense to port engine code to C# unless they wanted it to run slower.

What are these fundamental design trade offs?

Guys I beg you, is there any chance I will get my answers? ;)

Sorry got carried away. Ola and others know better.

[po via Digitalmars-d]

Post by Araq via Digitalmars-d

Post by po via Digitalmars-d
It doesn't mention anything about moving C++ into C#.
Even with IL2CPP, C# has fundamental design trade offs that
make it slower than C++(GC is just one of them), so it
wouldn't make much sense to port engine code to C# unless they
wanted it to run slower.

What are these fundamental design trade offs?

-GC
-no meta programming vs meta programming
-defaults to ref semantics C# vs value semantics C++
-C++ supports unique types, C# does not
-C# lambda automatic/GC, C++ lambda fully customized via capture
list

Post by Araq via Digitalmars-d
Guys I beg you, is there any chance I will get my answers? ;)

Sorry no clue what C++ features will be supported! Just glad
that a language is acknowledging how important it is to inter-op
with C++ for once.

Post by Araq via Digitalmars-d
C has fundamental design trade offs that make it slower than
Assembly
(function prologs is just of them), so it wouldn't make much
sense to port engine code to C unless they wanted it to run
slower.

I don't really think this is the same situations. I don't think
C# is any higher level than C++. Having a GC does not make it
automatically a higher level language, nor does it make it more
"productive".

That said, I think it is much easier to be productive in C# if
you are starting from scratch, but with the proper setup & in
depth knowledge of C++, it is every bit as productive(especially
in games, where things like GC end up as more of a burden).

[simendsjo via Digitalmars-d]

Post by po via Digitalmars-d

Post by Araq via Digitalmars-d

Post by po via Digitalmars-d
It doesn't mention anything about moving C++ into C#.
Even with IL2CPP, C# has fundamental design trade offs that make it
slower than C++(GC is just one of them), so it wouldn't make much
sense to port engine code to C# unless they wanted it to run slower.

What are these fundamental design trade offs?

-GC
-no meta programming vs meta programming

(...)

C# has wonderful meta-programming facilities: Generics! (/me run and hides)

[Paulo Pinto via Digitalmars-d]

Post by po via Digitalmars-d

Post by Araq via Digitalmars-d

Post by po via Digitalmars-d
It doesn't mention anything about moving C++ into C#.
Even with IL2CPP, C# has fundamental design trade offs that make it
slower than C++(GC is just one of them), so it wouldn't make much
sense to port engine code to C# unless they wanted it to run slower.

What are these fundamental design trade offs?

-GC
-no meta programming vs meta programming

C# has meta programming capabilities via attributes, MSIL manipulation,
reflection and having the compiler available as a library.

It is not as powerful or clean as D, but it gets the job done in many cases.

Post by po via Digitalmars-d
-defaults to ref semantics C# vs value semantics C++

Yes, it is a bummer, but they do exist to a certain extent. One just
needs to make use of them.

Post by po via Digitalmars-d
-C++ supports unique types, C# does not

Lost me there.

Post by po via Digitalmars-d
-C# lambda automatic/GC, C++ lambda fully customized via capture list

Which very few people understand properly and end up capturing the whole
environment anyway.

Post by po via Digitalmars-d
...
I don't really think this is the same situations. I don't think C# is
any higher level than C++. Having a GC does not make it automatically a
higher level language, nor does it make it more "productive".
That said, I think it is much easier to be productive in C# if you are
starting from scratch, but with the proper setup & in depth knowledge of
C++, it is every bit as productive(especially in games, where things
like GC end up as more of a burden).

The problem is not everyone has good knowledge of C++.

I do use C++ on and off since 1993, and always advocated it vs C when it
was considered slow(!). However I very seldom met fellow developers on
projects with similar C++ knowledge, except for the time I spent at CERN.

I follow at the distance the game industry, having tried a few times in
the past to be part of it. I was an IGDA member for a while, did attend
developer meetups at the game development university in DÃŒsseldorf and
buy regularly the game's development magazine of German studios.

Many middle size studios in Germany are now betting in C#
(Unity/MonoGame) and Flash. Mostly for tooling and indie quality games,
but sometimes all the way to production.

If D had already a GC that could rival with the CLR GC, it would be a
great alternative for the said studios. Regardless what the decision
regarding the D's answer to memory management will be.

Specially given that it can interoperate better with C and C++ than the
marshalling required by the alternatives.

--
Paulo

[Paulo Pinto via Digitalmars-d]

Post by po via Digitalmars-d

Post by Paulo Pinto via Digitalmars-d
This will most likely change when they get their IL2CPP
production ready and start moving code from C++ to C#.
Or when Microsoft finishes the ongoing work on .NET Native.
--
Paulo

http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-in-unity/
It appears to act as a replacement for the mono VM, allowing
for AoT compilation of .Net IL into C++, so that they can
benefit from existing C++ compiler tech.
It doesn't mention anything about moving C++ into C#.

No, but it is a possibility.

Post by po via Digitalmars-d
Even with IL2CPP, C# has fundamental design trade offs that
make it slower than C++(GC is just one of them), so it wouldn't
make much sense to port engine code to C# unless they wanted it
to run slower.

C has fundamental design trade offs that make it slower than
Assembly
(function prologs is just of them), so it wouldn't make much
sense to port engine code to C unless they wanted it to run
slower.

I have been through this discussion cycle a few times since the
Z80.

--
Paulo

[Paulo Pinto via Digitalmars-d]

On Tuesday, 30 September 2014 at 08:48:19 UTC, Szymon Gatner

Post by Szymon Gatner via Digitalmars-d

On Monday, 29 September 2014 at 10:00:27 UTC, Szymon Gatner
Is that all it would take? Do you also need a GC-free standard
library, which seems to be the need of all the others saying
"do this and I'll switch from C++"? Are the tools good enough?

Considered how many games (and I don't mean indie anymore, but
for example Blizzard's Heartstone) are now created in Unity
which uses not only GC but runs in Mono I am very skeptical of
anybody claiming GC is a no-go for games. - Especially- that
native executable is being built in case of D.

BlueByte latest games are done in Flash.

There is an article on the German magazine Making Games about
their experience switching from being hardcore C++ guys into the
world of Flash and Stage3D.

Post by Szymon Gatner via Digitalmars-d
I realize AAA's have have their reasons against GC i but in
that case one should probably just get UE4 license anyway.

Which also offers a C++ GC API, although quite limited from what
I have read.

Sometimes it seems the whole Assembly vs C vs Pascal, followed by
C vs C++ performance discussions all over again.


--
Paulo

[Ethan via Digitalmars-d]

On Tuesday, 30 September 2014 at 08:48:19 UTC, Szymon Gatner

Post by Szymon Gatner via Digitalmars-d
Considered how many games (and I don't mean indie anymore, but
for example Blizzard's Heartstone) are now created in Unity
which uses not only GC but runs in Mono I am very skeptical of
anybody claiming GC is a no-go for games. - Especially- that
native executable is being built in case of D.
I realize AAA's have have their reasons against GC i but in
that case one should probably just get UE4 license anyway.

Hello. AAA developer (Remedy) here using D. Custom tech, with a
custom binding solution written originally by Manu and continued
by myself.

A GC itself is not a bad thing. The implementation, however, is.

With a codebase like ours (mostly C++, some D), there's a few
things we need. Deterministic garbage collection is a big one -
when our C++ object is being destroyed, we need the D object to
be destroyed at the same time in most cases. This can be handled
by calling GC.collect() often, but that's where the next thing
comes in - the time the GC needs. If the time isn't being
scheduled at object destruction, then it all gets lumped together
in the GC collect. It automatically moves the time cost to a
place where we may not want it.

ARC garbage collection would certainly be beneficial there. I
looked in to adding support at a language level and at a library
level for it, but the time it would have taken for me to learn
both of those well enough to not muck it up is not feasible.
Writing a garbage collector that we have greater control over
will also take up too much time. The simpler solution is to
enforce coding standards that avoid triggering the GC.

It's something I will look at again in the future, to be sure.
And also to be sure, nothing is being done in Unity to the scale
we do stuff in our engine (at least, nothing in Unity that also
doesn't use a ton of native code to bypass Unity's limitations).

[Sean Kelly via Digitalmars-d]

Post by Ethan via Digitalmars-d
With a codebase like ours (mostly C++, some D), there's a few
things we need. Deterministic garbage collection is a big one -
when our C++ object is being destroyed, we need the D object to
be destroyed at the same time in most cases. This can be
handled by calling GC.collect() often, but that's where the
next thing comes in - the time the GC needs. If the time isn't
being scheduled at object destruction, then it all gets lumped
together in the GC collect. It automatically moves the time
cost to a place where we may not want it.

Would delete on the D side work here? Or the more current
destroy()? ie. is release of the memory a crucial part of the
equation, or merely finalization?

[Ethan via Digitalmars-d]

Post by Sean Kelly via Digitalmars-d
Would delete on the D side work here? Or the more current
destroy()? ie. is release of the memory a crucial part of the
equation, or merely finalization?

Destruction of an object is *far* more important than releasing
memory. Our D code's memory usage is drops in an ocean, but it
can potentially hold on to resources that need to be destroyed in
special ways depending on middleware/threading usage.

Object.destroy() would do the job, but there's also a
fragmentation problem that creeps in to a GC solution like the
default D implementation the longer you have your application
running. We already encounter plenty of cache-incoherent code in
other areas of the codebase, and since one of my roles is to
evangelise D (so to speak) I'm aiming to keep it running fast and
avoiding as many stalls as possible. If I avoid the current
implementation's garbage collection, then memory allocated stays
in roughly the same region (some work that I did manage to do and
intend on submitting a pull request for allows a user to specify
a custom set of allocation functions, so all memory from core and
phobos goes through our supplied memory allocator).

Either way, it still comes down to a function call to free your
object which means you're stepping outside of the way the GC
natively does things.

[Sean Kelly via Digitalmars-d]

Post by Ethan via Digitalmars-d
With a codebase like ours (mostly C++, some D), there's a few
things we need. Deterministic garbage collection is a big one -
when our C++ object is being destroyed, we need the D object to
be destroyed at the same time in most cases. This can be
handled by calling GC.collect() often, but that's where the
next thing comes in - the time the GC needs. If the time isn't
being scheduled at object destruction, then it all gets lumped
together in the GC collect. It automatically moves the time
cost to a place where we may not want it.

Would delete on the D side work here? Or the more current
destroy()? ie. is release of the memory a crucial part of the
equation, or merely finalization?

[Cliff via Digitalmars-d]

Post by Ethan via Digitalmars-d
Hello. AAA developer (Remedy) here using D. Custom tech, with a
custom binding solution written originally by Manu and
continued by myself.
A GC itself is not a bad thing. The implementation, however, is.
With a codebase like ours (mostly C++, some D), there's a few
things we need. Deterministic garbage collection is a big one -
when our C++ object is being destroyed, we need the D object to
be destroyed at the same time in most cases. This can be
handled by calling GC.collect() often, but that's where the
next thing comes in - the time the GC needs. If the time isn't
being scheduled at object destruction, then it all gets lumped
together in the GC collect. It automatically moves the time
cost to a place where we may not want it.

Not a GC specialist here, so maybe the thought arises - why not
turn off automatic GC until such times in the code where you can
afford the cost of it, then call GC.collect explicitly -
essentially eliminating the opportunity for the GC to run at
random times and force running at deterministic times? Is memory
usage so constrained that failing to execute runs in-between
those deterministic blocks could lead to OOM? Does such a
strategy have other nasty side-effects which make it impractical?

[via Digitalmars-d]

Post by Cliff via Digitalmars-d
Not a GC specialist here, so maybe the thought arises - why not
turn off automatic GC until such times in the code where you can
afford the cost of it, then call GC.collect explicitly -
essentially eliminating the opportunity for the GC to run at
random times and force running at deterministic times? Is
memory
usage so constrained that failing to execute runs in-between
those deterministic blocks could lead to OOM? Does such a
strategy have other nasty side-effects which make it
impractical?

The latter. If you want a game to run at 60 fps, you have about
16 ms for each frame, during which time you need to make all the
necessary game and graphics updates. There's no upper to limit to
the amount of time a GC run can take, so it can easily exceed the
few ms you have left for it.

There are however GC algorithms that support incremental
collection, meaning that you can give the GC a deadline. If it
can't finish before this deadline, it will have to interrupt its
work and continue on the next run. Unfortunately, these GCs
usually require special compiler support (barriers, and
distinguishing GC from non-GC pointers), which we don't have. But
there is CDGC writte by Leandro Lucarella for D1, which uses a
forking to achieve the same effect, and which Dicebot is
currently porting to D2:
http://forum.dlang.org/thread/exfrifcfczgjwkudqdgx at forum.dlang.org

[Kiith-Sa via Digitalmars-d]

Post by Chris via Digitalmars-d
On Tuesday, 30 September 2014 at 08:48:19 UTC, Szymon Gatner

Post by Szymon Gatner via Digitalmars-d
Considered how many games (and I don't mean indie anymore, but
for example Blizzard's Heartstone) are now created in Unity
which uses not only GC but runs in Mono I am very skeptical of
anybody claiming GC is a no-go for games. - Especially- that
native executable is being built in case of D.
I realize AAA's have have their reasons against GC i but in
that case one should probably just get UE4 license anyway.

Hello. AAA developer (Remedy) here using D. Custom tech, with a
custom binding solution written originally by Manu and
continued by myself.
A GC itself is not a bad thing. The implementation, however, is.
With a codebase like ours (mostly C++, some D), there's a few
things we need. Deterministic garbage collection is a big one -
when our C++ object is being destroyed, we need the D object to
be destroyed at the same time in most cases. This can be
handled by calling GC.collect() often, but that's where the
next thing comes in - the time the GC needs. If the time isn't
being scheduled at object destruction, then it all gets lumped
together in the GC collect. It automatically moves the time
cost to a place where we may not want it.
ARC garbage collection would certainly be beneficial there. I
looked in to adding support at a language level and at a
library level for it, but the time it would have taken for me
to learn both of those well enough to not muck it up is not
feasible. Writing a garbage collector that we have greater
control over will also take up too much time. The simpler
solution is to enforce coding standards that avoid triggering
the GC.
It's something I will look at again in the future, to be sure.
And also to be sure, nothing is being done in Unity to the
scale we do stuff in our engine (at least, nothing in Unity
that also doesn't use a ton of native code to bypass Unity's
limitations).

GC.free() can be used to manually delete GC-allocated data.
(destroy() must be called first to call te destructor, though) -
delete does both but is deprecated. You could write a simple RAII
pointer wrapper if you don't want to always call
destroy()+GC.free() manually.

Or do you need something else?

[Paulo Pinto via Digitalmars-d]

Post by Chris via Digitalmars-d
On Tuesday, 30 September 2014 at 08:48:19 UTC, Szymon Gatner

Post by Szymon Gatner via Digitalmars-d
Considered how many games (and I don't mean indie anymore, but
for example Blizzard's Heartstone) are now created in Unity
which uses not only GC but runs in Mono I am very skeptical of
anybody claiming GC is a no-go for games. - Especially- that
native executable is being built in case of D.
I realize AAA's have have their reasons against GC i but in
that case one should probably just get UE4 license anyway.

Hello. AAA developer (Remedy) here using D. Custom tech, with a
custom binding solution written originally by Manu and
continued by myself.
A GC itself is not a bad thing. The implementation, however, is.
With a codebase like ours (mostly C++, some D), there's a few
things we need. Deterministic garbage collection is a big one -
when our C++ object is being destroyed, we need the D object to
be destroyed at the same time in most cases. This can be
handled by calling GC.collect() often, but that's where the
next thing comes in - the time the GC needs. If the time isn't
being scheduled at object destruction, then it all gets lumped
together in the GC collect. It automatically moves the time
cost to a place where we may not want it.
ARC garbage collection would certainly be beneficial there. I
looked in to adding support at a language level and at a
library level for it, but the time it would have taken for me
to learn both of those well enough to not muck it up is not
feasible. Writing a garbage collector that we have greater
control over will also take up too much time. The simpler
solution is to enforce coding standards that avoid triggering
the GC.
It's something I will look at again in the future, to be sure.
And also to be sure, nothing is being done in Unity to the
scale we do stuff in our engine (at least, nothing in Unity
that also doesn't use a ton of native code to bypass Unity's
limitations).

Thanks for the feedback, quite interesting.

[Paulo Pinto via Digitalmars-d]

Post by Chris via Digitalmars-d
On Tuesday, 30 September 2014 at 08:48:19 UTC, Szymon Gatner

Post by Szymon Gatner via Digitalmars-d
Considered how many games (and I don't mean indie anymore, but
for example Blizzard's Heartstone) are now created in Unity
which uses not only GC but runs in Mono I am very skeptical of
anybody claiming GC is a no-go for games. - Especially- that
native executable is being built in case of D.
I realize AAA's have have their reasons against GC i but in
that case one should probably just get UE4 license anyway.

Hello. AAA developer (Remedy) here using D. Custom tech, with a
custom binding solution written originally by Manu and
continued by myself.
A GC itself is not a bad thing. The implementation, however, is.
With a codebase like ours (mostly C++, some D), there's a few
things we need. Deterministic garbage collection is a big one -
when our C++ object is being destroyed, we need the D object to
be destroyed at the same time in most cases. This can be
handled by calling GC.collect() often, but that's where the
next thing comes in - the time the GC needs. If the time isn't
being scheduled at object destruction, then it all gets lumped
together in the GC collect. It automatically moves the time
cost to a place where we may not want it.
ARC garbage collection would certainly be beneficial there. I
looked in to adding support at a language level and at a
library level for it, but the time it would have taken for me
to learn both of those well enough to not muck it up is not
feasible. Writing a garbage collector that we have greater
control over will also take up too much time. The simpler
solution is to enforce coding standards that avoid triggering
the GC.
It's something I will look at again in the future, to be sure.
And also to be sure, nothing is being done in Unity to the
scale we do stuff in our engine (at least, nothing in Unity
that also doesn't use a ton of native code to bypass Unity's
limitations).

Thanks for the feedback, quite interesting.

[Nick Sabalausky via Digitalmars-d]

Post by bachmeier via Digitalmars-d
Is that all it would take? Do you also need a GC-free standard
library, which seems to be the need of all the others saying "do this
and I'll switch from C++"? Are the tools good enough?

Considered how many games (and I don't mean indie anymore, but for
example Blizzard's Heartstone) are now created in Unity which uses not
only GC but runs in Mono I am very skeptical of anybody claiming GC is a
no-go for games.

The whole "Unity3D == Mono" thing is a somewhat inaccurate misconception.

Unity3D's engine (ie, the real workhorse of any Unity3D game) is written
in plain old native C++. So not *necessarily* GC (though they might
still use one internally, I wouldn't know).

Only the game-specific scripts (and I *think* the Unity3D Editor)
actually run on Mono. And even then, the game scripts *are* able to call
into C-linkage stuff, which *is* occasionally done to work around
performance issues within game scripts.

Also, I imagine Mono's GC is probably quite a bit better than D's
currently is.

[Szymon Gatner via Digitalmars-d]

On Tuesday, 14 October 2014 at 20:41:25 UTC, Nick Sabalausky

Post by Nick Sabalausky via Digitalmars-d

On Monday, 29 September 2014 at 10:00:27 UTC, Szymon Gatner
Is that all it would take? Do you also need a GC-free standard
library, which seems to be the need of all the others saying
"do this
and I'll switch from C++"? Are the tools good enough?

Considered how many games (and I don't mean indie anymore, but for
example Blizzard's Heartstone) are now created in Unity which
uses not
only GC but runs in Mono I am very skeptical of anybody
claiming GC is a
no-go for games.

The whole "Unity3D == Mono" thing is a somewhat inaccurate
misconception.
Unity3D's engine (ie, the real workhorse of any Unity3D game)
is written in plain old native C++. So not *necessarily* GC
(though they might still use one internally, I wouldn't know).
Only the game-specific scripts (and I *think* the Unity3D
Editor) actually run on Mono. And even then, the game scripts
*are* able to call into C-linkage stuff, which *is*
occasionally done to work around performance issues within game
scripts.
Also, I imagine Mono's GC is probably quite a bit better than
D's currently is.

All good points. Still, my point was that GC does not mean
language is automatically excluded from gamedev.

[Paulo Pinto via Digitalmars-d]

On Tuesday, 14 October 2014 at 20:41:25 UTC, Nick Sabalausky

Post by Nick Sabalausky via Digitalmars-d

On Monday, 29 September 2014 at 10:00:27 UTC, Szymon Gatner
Is that all it would take? Do you also need a GC-free standard
library, which seems to be the need of all the others saying
"do this
and I'll switch from C++"? Are the tools good enough?

Considered how many games (and I don't mean indie anymore, but for
example Blizzard's Heartstone) are now created in Unity which
uses not
only GC but runs in Mono I am very skeptical of anybody
claiming GC is a
no-go for games.

The whole "Unity3D == Mono" thing is a somewhat inaccurate
misconception.
Unity3D's engine (ie, the real workhorse of any Unity3D game)
is written in plain old native C++. So not *necessarily* GC
(though they might still use one internally, I wouldn't know).
Only the game-specific scripts (and I *think* the Unity3D
Editor) actually run on Mono. And even then, the game scripts
*are* able to call into C-linkage stuff, which *is*
occasionally done to work around performance issues within game
scripts.
Also, I imagine Mono's GC is probably quite a bit better than
D's currently is.

Yeah, but on the other hand there are quite a few small studios
living off Air, LibGDX/jMonkeyEngine and XNA/MonoGame.

Which is an area where D could also appeal to indies.

One needs to start somewhere.

--
Paulo

[Walter Bright via Digitalmars-d]

Hi,
recently there is much talk about extending C++ interop in D but it is unclear
to me what that means. Functions and virtual class methods are already callable.
What else is planned in the near future? Exceptions? Support for C++ templates?
(that seems difficult no?).

Currently, D supports C++:

* function calling
* name mangling
* namespaces
* templates
* member functions
* single inheritance
* basic types that exist in C++ but not D (like 'long')

Note that there are no plans to support C++ semantics - the D side will support
only D semantic rules. SFINAE, Koenig lookup, etc., have no place in D.

C++ interop will require the user to be flexible on both the C++ and D side, and
bluntly will require strong knowledge of D and C++ and how they work under the
hood to be successful with it.

Probably the most tricky thing we're working on is interop with C++ exceptions.

Essentially, we're going to see how far we can push interop.

[Meta via Digitalmars-d]

Post by Walter Bright via Digitalmars-d
* function calling
* name mangling
* namespaces
* templates
* member functions
* single inheritance
* basic types that exist in C++ but not D (like 'long')
Note that there are no plans to support C++ semantics - the D
side will support only D semantic rules. SFINAE, Koenig lookup,
etc., have no place in D.
C++ interop will require the user to be flexible on both the
C++ and D side, and bluntly will require strong knowledge of D
and C++ and how they work under the hood to be successful with
it.
Probably the most tricky thing we're working on is interop with C++ exceptions.
Essentially, we're going to see how far we can push interop.

To clarify, templates have to be instantiated on the C++ side
before being passed to D, right? Is it correct that D can't
instantiate a C++ template?

[Andrei Alexandrescu via Digitalmars-d]

Post by Walter Bright via Digitalmars-d
* function calling
* name mangling
* namespaces
* templates
* member functions
* single inheritance
* basic types that exist in C++ but not D (like 'long')
Note that there are no plans to support C++ semantics - the D side
will support only D semantic rules. SFINAE, Koenig lookup, etc., have
no place in D.
C++ interop will require the user to be flexible on both the C++ and D
side, and bluntly will require strong knowledge of D and C++ and how
they work under the hood to be successful with it.
Probably the most tricky thing we're working on is interop with C++ exceptions.
Essentially, we're going to see how far we can push interop.

To clarify, templates have to be instantiated on the C++ side before
being passed to D, right? Is it correct that D can't instantiate a C++
template?

Correct. Here's the syntax on the C++ side:
http://en.wikipedia.org/wiki/C++11#Extern_template -- Andrei

[Szymon Gatner via Digitalmars-d]

On Tuesday, 14 October 2014 at 23:01:49 UTC, Andrei Alexandrescu

Post by Andrei Alexandrescu via Digitalmars-d

On Tuesday, 14 October 2014 at 22:27:35 UTC, Walter Bright

Post by Walter Bright via Digitalmars-d
* function calling
* name mangling
* namespaces
* templates
* member functions
* single inheritance
* basic types that exist in C++ but not D (like 'long')
Note that there are no plans to support C++ semantics - the D side
will support only D semantic rules. SFINAE, Koenig lookup,
etc., have
no place in D.
C++ interop will require the user to be flexible on both the
C++ and D
side, and bluntly will require strong knowledge of D and C++
and how
they work under the hood to be successful with it.
Probably the most tricky thing we're working on is interop
with C++
exceptions.
Essentially, we're going to see how far we can push interop.

To clarify, templates have to be instantiated on the C++ side
before
being passed to D, right? Is it correct that D can't
instantiate a C++
template?

http://en.wikipedia.org/wiki/C++11#Extern_template -- Andrei

Understood, makes sense.

[Jacob Carlborg via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d
http://en.wikipedia.org/wiki/C++11#Extern_template -- Andrei

"extern template class std::vector<MyClass>;

which tells the compiler NOT to instantiate the template in this
translation unit."

That sounds like the complete opposite of what's needed.

[Daniel N via Digitalmars-d]

On Wednesday, 15 October 2014 at 06:18:48 UTC, Jacob Carlborg

Post by Jacob Carlborg via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
http://en.wikipedia.org/wiki/C++11#Extern_template -- Andrei

"extern template class std::vector<MyClass>;
which tells the compiler NOT to instantiate the template in
this translation unit."
That sounds like the complete opposite of what's needed.

"C++03 has this syntax to oblige the compiler to instantiate a
template:

template class std::vector<MyClass>;"

[via Digitalmars-d]

Post by Daniel N via Digitalmars-d
"C++03 has this syntax to oblige the compiler to instantiate a
template class std::vector<MyClass>;"

But how does D handle concepts which most likely will be in the
C++14 standard?

http://concepts.axiomatics.org/~ans/

[Paulo Pinto via Digitalmars-d]

Am 15.10.2014 um 09:18 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=

Post by Daniel N via Digitalmars-d
template class std::vector<MyClass>;"

But how does D handle concepts which most likely will be in the C++14
standard?
http://concepts.axiomatics.org/~ans/

I imagine you meant C++17. C++14 is already ratified.

--
Paulo

[via Digitalmars-d]

Post by Paulo Pinto via Digitalmars-d
I imagine you meant C++17. C++14 is already ratified.

Yes, sorry, I meant that it is close enough for consideration as
a draft. So discussing the effects of it on D's C++ support is
now possible?

[Daniel N via Digitalmars-d]

On Wednesday, 15 October 2014 at 18:06:18 UTC, Ola Fosheim

On Wednesday, 15 October 2014 at 17:38:46 UTC, Paulo Pinto

Post by Paulo Pinto via Digitalmars-d
I imagine you meant C++17. C++14 is already ratified.

Yes, sorry, I meant that it is close enough for consideration
as a draft. So discussing the effects of it on D's C++ support
is now possible?

There's no impact, we already support it since the template is
instantiated from C++ side.

[via Digitalmars-d]

Post by Daniel N via Digitalmars-d
There's no impact, we already support it since the template is
instantiated from C++ side.

But you don't know the return type of the templated function
until you know which combination of templates it instantiated?

[Daniel N via Digitalmars-d]

On Thursday, 16 October 2014 at 05:45:00 UTC, Ola Fosheim GrÞstad

Post by via Digitalmars-d

Post by Daniel N via Digitalmars-d
There's no impact, we already support it since the template is
instantiated from C++ side.

But you don't know the return type of the templated function
until you know which combination of templates it instantiated?

Yes, but this is true already today for enable_if?

template<typename T>
std::enable_if_t<std::is_same<T, int>::value, float>
fun(const T& f)
{
return f;
}

template<typename T>
std::enable_if_t<std::is_same<T, float>::value, int>
fun(const T& f)
{
return f;
}

// Explicit Template Instantiation
template float fun(const int&);
template int fun(const float&);

[Andrei Alexandrescu via Digitalmars-d]

Post by Jacob Carlborg via Digitalmars-d

Post by Andrei Alexandrescu via Digitalmars-d
http://en.wikipedia.org/wiki/C++11#Extern_template -- Andrei

"extern template class std::vector<MyClass>;
which tells the compiler NOT to instantiate the template in this
translation unit."
That sounds like the complete opposite of what's needed.

C++11 includes C++03. -- Andrei

[Jacob Carlborg via Digitalmars-d]

Post by Andrei Alexandrescu via Digitalmars-d
C++11 includes C++03. -- Andrei

I kind of only read the C++11 part.

[Szymon Gatner via Digitalmars-d]

Post by Walter Bright via Digitalmars-d

Post by Szymon Gatner via Digitalmars-d
Hi,
recently there is much talk about extending C++ interop in D
but it is unclear
to me what that means. Functions and virtual class methods are already callable.
What else is planned in the near future? Exceptions? Support
for C++ templates?
(that seems difficult no?).

* function calling
* name mangling
* namespaces
* templates
* member functions
* single inheritance
* basic types that exist in C++ but not D (like 'long')

I do understand current situation tho I admit I am not aware of
the "single inheritance". Does it mean that one can derive in D
from a C++ class (don't see it in the docs)?

Post by Walter Bright via Digitalmars-d
Essentially, we're going to see how far we can push interop.

I suppose that is the answer I was looking for, time will tell
yes? :)

[Walter Bright via Digitalmars-d]

I do understand current situation tho I admit I am not aware of the "single
inheritance". Does it mean that one can derive in D from a C++ class (don't see
it in the docs)?

It's part of D's COM support.

[Wyatt via Digitalmars-d]

Post by Walter Bright via Digitalmars-d
* function calling
* name mangling
* namespaces
* templates
* member functions
* single inheritance
* basic types that exist in C++ but not D (like 'long')

I get the sense that http://dlang.org/cpp_interface needs some
updates then? At the very least, it mentions "...it is very
unlikely that any sort of reasonable method could be found to
express C++ templates in a link-compatible way with D."

Or am I misunderstanding what you mean with that bullet point?

-Wyatt

[Daniel Murphy via Digitalmars-d]

Post by Wyatt via Digitalmars-d
I get the sense that http://dlang.org/cpp_interface needs some
updates then? At the very least, it mentions "...it is very
unlikely that any sort of reasonable method could be found to
express C++ templates in a link-compatible way with D."
Or am I misunderstanding what you mean with that bullet point?

That page is many years out of date.