digitalmars.D - So what exactly is coming with extended C++ support?
- Szymon Gatner (17/17) Sep 29 2014 Hi,
- Jacob Carlborg (8/20) Sep 29 2014 Using templates are already supported. Note, they need to instantiated
- Szymon Gatner (6/19) Sep 30 2014 Ah, cool, but I still have no clue what to expect from ongoing
- bachmeier (10/15) Sep 29 2014 Is that all it would take? Do you also need a GC-free standard
- Wyatt (9/15) Sep 29 2014 No relation to OP, but I can tell you it is unbelievably more
- Szymon Gatner (27/38) Sep 30 2014 Considered how many games (and I don't mean indie anymore, but
- Chris (10/51) Sep 30 2014 Very interesting.
- Szymon Gatner (5/9) Sep 30 2014 I actually was planning on something like that. I am still
- John Colvin (3/16) Sep 30 2014 I presume you're familiar with http://code.dlang.org/packages/luad
- Szymon Gatner (4/22) Sep 30 2014 I am, but it is incredible how much of the binding-code can be
- Chris (6/19) Sep 30 2014 Great. I'm interested in Lua-D interaction. Would you share it on
- Szymon Gatner (6/10) Sep 30 2014 I was thinking about maybe just posting snippets on the blog but
- Szymon Gatner (3/5) Sep 30 2014 Forgot to reply to 2nd part: yes I looked at it and in fact I
- Dan Olson (9/12) Oct 14 2014 The iOS project with LDC has been idle during the windsurfing season
- Szymon Gatner (3/20) Oct 14 2014 That is good to hear indeed. In your estimate: how much longer
- Dan Olson (27/29) Oct 14 2014 Depends on your definition of "usable" Szymon.
- Szymon Gatner (8/30) Oct 15 2014 That is my definition :)
- Jacob Carlborg (13/25) Oct 15 2014 I will create Dub packages when I need some framework, unless someone
- Dan Olson (6/10) Oct 16 2014 Specifically here I mean LDC targeted to arm-ios. The linker complains
- Jacob Carlborg (4/7) Oct 17 2014 Oh, right. I was mostly thinking about OS X applications.
- Johnathan (8/10) Sep 30 2014 UE4 uses a GC internally. The issue with using D's GC for games
- Szymon Gatner (9/19) Sep 30 2014 True, but not in the sense that it is using GC-based language. It
- po (3/9) Sep 30 2014 Unity the engine is written in C++. When you create a game using
- Paulo Pinto (6/16) Sep 30 2014 This will most likely change when they get their IL2CPP
- po (10/15) Sep 30 2014 I'd not seen IL2CPP before, but from this link:
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (6/11) Sep 30 2014 Yes, the info on CIL instruction set suggests that is a very
- Araq (1/6) Sep 30 2014 What are these fundamental design trade offs?
- Szymon Gatner (2/8) Sep 30 2014 Guys I beg you, is there any chance I will get my answers? ;)
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (15/24) Sep 30 2014 http://en.wikipedia.org/wiki/List_of_CIL_instructions
- Szymon Gatner (27/40) Sep 30 2014 I suspected so :P
- Ola Fosheim Grostad (22/36) Sep 30 2014 I used some parts of boost c++0x std on ios a few years ago. I
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (7/14) Sep 30 2014 There's probably not much feature-wise that stands in the way of
- Paulo Pinto (2/10) Sep 30 2014 Sorry got carried away. Ola and others know better.
- po (18/30) Sep 30 2014 -GC
- simendsjo (3/13) Sep 30 2014 (...)
- Paulo Pinto (27/47) Sep 30 2014 C# has meta programming capabilities via attributes, MSIL manipulation,
- Paulo Pinto (11/28) Sep 30 2014 C has fundamental design trade offs that make it slower than
- Paulo Pinto (12/27) Sep 30 2014 BlueByte latest games are done in Flash.
- Ethan (26/33) Sep 30 2014 Hello. AAA developer (Remedy) here using D. Custom tech, with a
- Sean Kelly (4/13) Sep 30 2014 Would delete on the D side work here? Or the more current
- Ethan (20/23) Oct 01 2014 Destruction of an object is *far* more important than releasing
- Cliff (9/22) Sep 30 2014 Not a GC specialist here, so maybe the thought arises - why not
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (16/26) Oct 01 2014 The latter. If you want a game to run at 60 fps, you have about
- Kiith-Sa (7/43) Sep 30 2014 GC.free() can be used to manually delete GC-allocated data.
- Paulo Pinto (2/38) Oct 01 2014 Thanks for the feedback, quite interesting.
- Nick Sabalausky (11/22) Oct 14 2014 The whole "Unity3D == Mono" thing is a somewhat inaccurate misconception...
- Szymon Gatner (4/34) Oct 14 2014 All good points. Still, my point was that GC does not mean
- Paulo Pinto (8/38) Oct 15 2014 Yeah, but on the other hand there are quite a few small studios
- Walter Bright (16/21) Oct 14 2014 Currently, D supports C++:
- Meta (4/22) Oct 14 2014 To clarify, templates have to be instantiated on the C++ side
- Andrei Alexandrescu (3/29) Oct 14 2014 Correct. Here's the syntax on the C++ side:
- Szymon Gatner (3/41) Oct 14 2014 Understood, makes sense.
-
Jacob Carlborg
(7/9)
Oct 14 2014
"extern template class std::vector
; - Daniel N (5/12) Oct 14 2014 "C++03 has this syntax to oblige the compiler to instantiate a
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (4/7) Oct 15 2014 But how does D handle concepts which most likely will be in the
- Paulo Pinto (5/12) Oct 15 2014 I imagine you meant C++17. C++14 is already ratified.
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (4/5) Oct 15 2014 Yes, sorry, I meant that it is close enough for consideration as
- Daniel N (4/11) Oct 15 2014 There's no impact, we already support it since the template is
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (3/5) Oct 15 2014 But you don't know the return type of the templated function
- Daniel N (18/23) Oct 17 2014 Yes, but this is true already today for enable_if?
- "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= (9/14) Oct 17 2014 That sounds right, but I think the combination of auto + concepts
- Andrei Alexandrescu (2/9) Oct 15 2014 C++11 includes C++03. -- Andrei
- Jacob Carlborg (4/5) Oct 15 2014 I kind of only read the C++11 part.
- Szymon Gatner (6/25) Oct 14 2014 I do understand current situation tho I admit I am not aware of
- Walter Bright (2/5) Oct 14 2014 It's part of D's COM support.
- Wyatt (7/15) Oct 15 2014 I get the sense that http://dlang.org/cpp_interface needs some
- Daniel Murphy (2/8) Oct 15 2014 That page is many years out of date.
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.
Sep 29 2014
On 29/09/14 12:00, Szymon Gatner wrote: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 -- /Jacob Carlborg
Sep 29 2014
On Monday, 29 September 2014 at 14:36:10 UTC, Jacob Carlborg wrote:On 29/09/14 12:00, Szymon Gatner wrote:Ah, cool, but I still have no clue what to expect from ongoing discussion on C++ interop. Does anyone know?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.[1] https://github.com/D-Programming-Language/dmd/pull/3987Yup, I saw it and this makes me very happy. iOS run-time is still an issue tho.
Sep 30 2014
On Monday, 29 September 2014 at 10:00:27 UTC, Szymon Gatner wrote: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.
Sep 29 2014
On Monday, 29 September 2014 at 20:15:06 UTC, bachmeier wrote: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.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
Sep 29 2014
On Monday, 29 September 2014 at 20:15:06 UTC, bachmeier wrote:On Monday, 29 September 2014 at 10:00:27 UTC, Szymon Gatner wrote: 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.
Sep 30 2014
On Tuesday, 30 September 2014 at 08:48:19 UTC, Szymon Gatner wrote:On Monday, 29 September 2014 at 20:15:06 UTC, bachmeier wrote:Very interesting.On Monday, 29 September 2014 at 10:00:27 UTC, Szymon Gatner wrote: 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.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.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.
Sep 30 2014
On Tuesday, 30 September 2014 at 09:32:05 UTC, Chris wrote: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!
Sep 30 2014
On Tuesday, 30 September 2014 at 10:06:47 UTC, Szymon Gatner wrote:On Tuesday, 30 September 2014 at 09:32:05 UTC, Chris wrote:I presume you're familiar with http://code.dlang.org/packages/luadIt'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!
Sep 30 2014
On Tuesday, 30 September 2014 at 10:39:53 UTC, John Colvin wrote:On Tuesday, 30 September 2014 at 10:06:47 UTC, Szymon Gatner wrote: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? :POn Tuesday, 30 September 2014 at 09:32:05 UTC, Chris wrote:I presume you're familiar with http://code.dlang.org/packages/luadIt'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!
Sep 30 2014
On Tuesday, 30 September 2014 at 10:06:47 UTC, Szymon Gatner wrote:On Tuesday, 30 September 2014 at 09:32:05 UTC, Chris wrote: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/DerelictLuaIt'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!
Sep 30 2014
On Tuesday, 30 September 2014 at 11:46:30 UTC, Chris wrote: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/DerelictLuaI 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.
Sep 30 2014
On Tuesday, 30 September 2014 at 11:46:30 UTC, Chris wrote:Have you had a look at DerelictLua: https://github.com/DerelictOrg/DerelictLuaForgot to reply to 2nd part: yes I looked at it and in fact I tried my code using it.
Sep 30 2014
"Chris" <wendlec tcd.ie> writes: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). -- dano
Oct 14 2014
On Tuesday, 14 October 2014 at 16:09:31 UTC, Dan Olson wrote:"Chris" <wendlec tcd.ie> writes:That is good to hear indeed. In your estimate: how much longer until D is usable on iOS?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).
Oct 14 2014
"Szymon Gatner" <noemail gmail.com> writes: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. -- dano
Oct 14 2014
On Wednesday, 15 October 2014 at 06:50:55 UTC, Dan Olson wrote:"Szymon Gatner" <noemail gmail.com> writes:That is my definition :) I would use static D library in C++ iOS application.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.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.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 thatThen 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.RightOh, and compiling to arm64 for newer devices.Knowing Apple that will be mandatory for new apps soon. Thanks for all your work!
Oct 15 2014
On 2014-10-15 08:50, Dan Olson wrote: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.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.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.Then there are all the tool related things that might hinder D use on iOS. Things such as no source level debuggingI think I have used Xcode to debug a D application.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. -- /Jacob Carlborg
Oct 15 2014
Jacob Carlborg <doob me.com> writes:On 2014-10-15 08:50, Dan Olson wrote: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. -- danoThen there are all the tool related things that might hinder D use on iOS. Things such as no source level debuggingI think I have used Xcode to debug a D application.
Oct 16 2014
On 2014-10-16 17:21, Dan Olson wrote: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.Oh, right. I was mostly thinking about OS X applications. -- /Jacob Carlborg
Oct 17 2014
On Tuesday, 30 September 2014 at 08:48:19 UTC, Szymon Gatner wrote: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.
Sep 30 2014
On Tuesday, 30 September 2014 at 09:53:41 UTC, Johnathan wrote:On Tuesday, 30 September 2014 at 08:48:19 UTC, Szymon Gatner wrote:True, but not in the sense that it is using GC-based language. It is custom C++ solution tailored for the purpose.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.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.
Sep 30 2014
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 different than the countless games that do the same using Lua.
Sep 30 2014
On Tuesday, 30 September 2014 at 13:29:15 UTC, po wrote:This will most likely change when they get their IL2CPP Or when Microsoft finishes the ongoing work on .NET Native. -- PauloAll 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 no different than the countless games that do the same using Lua.
Sep 30 2014
This will most likely change when they get their IL2CPP Or when Microsoft finishes the ongoing work on .NET Native. -- PauloI'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 slower than C++(GC is just one of them), so it wouldn't make slower.
Sep 30 2014
On Tuesday, 30 September 2014 at 13:59:01 UTC, po wrote:make it slower than C++(GC is just one of them), so it wouldn't 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.
Sep 30 2014
make it slower than C++(GC is just one of them), so it wouldn't to run slower.What are these fundamental design trade offs?
Sep 30 2014
On Tuesday, 30 September 2014 at 14:19:51 UTC, Araq wrote:Guys I beg you, is there any chance I will get my answers? ;)make it slower than C++(GC is just one of them), so it wanted it to run slower.What are these fundamental design trade offs?
Sep 30 2014
On Tuesday, 30 September 2014 at 14:28:49 UTC, Szymon Gatner wrote:On Tuesday, 30 September 2014 at 14:19:51 UTC, Araq wrote:http://en.wikipedia.org/wiki/List_of_CIL_instructionsmake it slower than C++(GC is just one of them), so it 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? ;)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?
Sep 30 2014
On Tuesday, 30 September 2014 at 14:34:49 UTC, Ola Fosheim Grøstad wrote:I suspected so :PGuys 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.Great.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.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 :(
Sep 30 2014
On Tuesday, 30 September 2014 at 17:11:48 UTC, Szymon Gatner wrote: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?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.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 thisWell, 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! :-)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?
Sep 30 2014
On Tuesday, 30 September 2014 at 19:47:32 UTC, Ola Fosheim Grostad wrote: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.
Sep 30 2014
Am 30.09.2014 16:28, schrieb Szymon Gatner:On Tuesday, 30 September 2014 at 14:19:51 UTC, Araq wrote:Sorry got carried away. Ola and others know better.Guys I beg you, is there any chance I will get my answers? ;)slower than C++(GC is just one of them), so it wouldn't make muchWhat are these fundamental design trade offs?
Sep 30 2014
On Tuesday, 30 September 2014 at 14:19:51 UTC, Araq wrote:-GC -no meta programming vs meta programming listmake it slower than C++(GC is just one of them), so it 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 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.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 automatically a higher level language, nor does it make it more "productive". 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).
Sep 30 2014
On 09/30/2014 05:32 PM, po wrote:On Tuesday, 30 September 2014 at 14:19:51 UTC, Araq wrote:(...)-GC -no meta programming vs meta programmingslower than C++(GC is just one of them), so it wouldn't make muchWhat are these fundamental design trade offs?
Sep 30 2014
Am 30.09.2014 17:32, schrieb po:On Tuesday, 30 September 2014 at 14:19:51 UTC, Araq wrote: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.-GC -no meta programming vs meta programmingslower than C++(GC is just one of them), so it wouldn't make muchWhat are these fundamental design trade offs?Yes, it is a bummer, but they do exist to a certain extent. One just needs to make use of them.Lost me there.Which very few people understand properly and end up capturing the whole environment anyway.... any higher level than C++. Having a GC does not make it automatically a higher level language, nor does it make it more "productive". 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. (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
Sep 30 2014
On Tuesday, 30 September 2014 at 13:59:01 UTC, po wrote:No, but it is a possibility.This will most likely change when they get their IL2CPP Or when Microsoft finishes the ongoing work on .NET Native. -- PauloI'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.make it slower than C++(GC is just one of them), so it wouldn't 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
Sep 30 2014
On Tuesday, 30 September 2014 at 08:48:19 UTC, Szymon Gatner wrote:On Monday, 29 September 2014 at 20:15:06 UTC, bachmeier wrote: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.On Monday, 29 September 2014 at 10:00:27 UTC, Szymon Gatner wrote: 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.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
Sep 30 2014
On Tuesday, 30 September 2014 at 08:48:19 UTC, Szymon Gatner wrote: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).
Sep 30 2014
On Tuesday, 30 September 2014 at 21:19:44 UTC, Ethan wrote: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?
Sep 30 2014
On Tuesday, 30 September 2014 at 22:32:26 UTC, Sean Kelly wrote: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.
Oct 01 2014
On Tuesday, 30 September 2014 at 21:19:44 UTC, Ethan wrote: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?
Sep 30 2014
On Tuesday, 30 September 2014 at 23:31:36 UTC, Cliff wrote: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 forum.dlang.org
Oct 01 2014
On Tuesday, 30 September 2014 at 21:19:44 UTC, Ethan wrote:On Tuesday, 30 September 2014 at 08:48:19 UTC, Szymon Gatner wrote: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?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).
Sep 30 2014
On Tuesday, 30 September 2014 at 21:19:44 UTC, Ethan wrote:On Tuesday, 30 September 2014 at 08:48:19 UTC, Szymon Gatner wrote:Thanks for the feedback, quite interesting.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).
Oct 01 2014
On 09/30/2014 04:48 AM, Szymon Gatner wrote:On Monday, 29 September 2014 at 20:15:06 UTC, bachmeier wrote: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.On Monday, 29 September 2014 at 10:00:27 UTC, Szymon Gatner wrote: 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.
Oct 14 2014
On Tuesday, 14 October 2014 at 20:41:25 UTC, Nick Sabalausky wrote:On 09/30/2014 04:48 AM, Szymon Gatner wrote:All good points. Still, my point was that GC does not mean language is automatically excluded from gamedev.On Monday, 29 September 2014 at 20:15:06 UTC, bachmeier wrote: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.On Monday, 29 September 2014 at 10:00:27 UTC, Szymon Gatner wrote: 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.
Oct 14 2014
On Tuesday, 14 October 2014 at 20:41:25 UTC, Nick Sabalausky wrote:On 09/30/2014 04:48 AM, Szymon Gatner wrote: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. -- PauloOn Monday, 29 September 2014 at 20:15:06 UTC, bachmeier wrote: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.On Monday, 29 September 2014 at 10:00:27 UTC, Szymon Gatner wrote: 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.
Oct 15 2014
On 9/29/2014 3:00 AM, Szymon Gatner wrote: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.
Oct 14 2014
On Tuesday, 14 October 2014 at 22:27:35 UTC, Walter Bright wrote: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.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?
Oct 14 2014
On 10/14/14, 3:53 PM, Meta wrote:On Tuesday, 14 October 2014 at 22:27:35 UTC, Walter Bright wrote:Correct. Here's the syntax on the C++ side: http://en.wikipedia.org/wiki/C++11#Extern_template -- AndreiCurrently, 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.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?
Oct 14 2014
On Tuesday, 14 October 2014 at 23:01:49 UTC, Andrei Alexandrescu wrote:On 10/14/14, 3:53 PM, Meta wrote:Understood, makes sense.On Tuesday, 14 October 2014 at 22:27:35 UTC, Walter Bright wrote:Correct. Here's the syntax on the C++ side: http://en.wikipedia.org/wiki/C++11#Extern_template -- AndreiCurrently, 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.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?
Oct 14 2014
On 2014-10-15 01:01, Andrei Alexandrescu wrote:Correct. Here's the syntax on the C++ side: 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. -- /Jacob Carlborg
Oct 14 2014
On Wednesday, 15 October 2014 at 06:18:48 UTC, Jacob Carlborg wrote:On 2014-10-15 01:01, Andrei Alexandrescu wrote:"C++03 has this syntax to oblige the compiler to instantiate a template: template class std::vector<MyClass>;"Correct. Here's the syntax on the C++ side: 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.
Oct 14 2014
On Wednesday, 15 October 2014 at 06:29:40 UTC, Daniel N wrote:"C++03 has this syntax to oblige the compiler to instantiate a template: 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/
Oct 15 2014
Am 15.10.2014 um 09:18 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang gmail.com>":On Wednesday, 15 October 2014 at 06:29:40 UTC, Daniel N wrote:I imagine you meant C++17. C++14 is already ratified. -- Paulo"C++03 has this syntax to oblige the compiler to instantiate a template: 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/
Oct 15 2014
On Wednesday, 15 October 2014 at 17:38:46 UTC, Paulo Pinto wrote: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?
Oct 15 2014
On Wednesday, 15 October 2014 at 18:06:18 UTC, Ola Fosheim Grøstad wrote:On Wednesday, 15 October 2014 at 17:38:46 UTC, Paulo Pinto wrote:There's no impact, we already support it since the template is instantiated from C++ side.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?
Oct 15 2014
On Thursday, 16 October 2014 at 03:53:53 UTC, Daniel N wrote: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?
Oct 15 2014
On Thursday, 16 October 2014 at 05:45:00 UTC, Ola Fosheim Grøstad wrote:On Thursday, 16 October 2014 at 03:53:53 UTC, Daniel N wrote: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&);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?
Oct 17 2014
On Friday, 17 October 2014 at 09:39:27 UTC, Daniel N wrote:On Thursday, 16 October 2014 at 05:45:00 UTC, Ola Fosheim Grøstad wrote:That sounds right, but I think the combination of auto + concepts will make it easy to do and it might turn into a common paradigm… Composing the most efficient return object based on some constraints generally sounds like a good idea when people get used to using auto for capturing return types. After having watched some of the cppcon videos I am getting the impression that C++ will be more and more difficult to interface with without building "clang" into the compiler.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?
Oct 17 2014
On 10/14/14, 11:18 PM, Jacob Carlborg wrote:On 2014-10-15 01:01, Andrei Alexandrescu wrote:C++11 includes C++03. -- AndreiCorrect. Here's the syntax on the C++ side: 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.
Oct 15 2014
On 2014-10-15 19:31, Andrei Alexandrescu wrote:C++11 includes C++03. -- AndreiI kind of only read the C++11 part. -- /Jacob Carlborg
Oct 15 2014
On Tuesday, 14 October 2014 at 22:27:35 UTC, Walter Bright wrote:On 9/29/2014 3:00 AM, Szymon Gatner wrote: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)?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')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? :)
Oct 14 2014
On 10/14/2014 5:40 PM, Szymon Gatner wrote: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.
Oct 14 2014
On Tuesday, 14 October 2014 at 22:27:35 UTC, Walter Bright wrote: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')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
Oct 15 2014
"Wyatt" wrote in message news:vhwivrusiysydgkxrjqw forum.dlang.org...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.
Oct 15 2014