3 ms·

As a D programmer currently making a small game engine + networked rts game in the language, invariant blocks are another thing I really enjoy about the languag

by Profan 11y ago

As a D programmer currently making a small game engine + networked rts game in the language, invariant blocks are another thing I really enjoy about the language: http://dlang.org/contracts.html#Invariants http://dlang.org/contracts.html#Invariants Lets you specify contracts which are asserted on construction and destruction, it's great. The meta programming is also wonderful for things like serialization of data, simply iterating over a type's members at compile-time to generate serialization code, cutting out much bloated code. It's worth noting that it's metaprogramming for humans, _compared_ to c++, but sometimes leaves a bit to be desired documentation-wise, all the building blocks are there, but sometimes you'd like to not need to reinvent the wheel every time you attempt some metaprogramming-related task. Things I don't enjoy include the core language's reliance on the GC, including things like exceptions relying on GC allocations. Thankfully they've made it a bit easier to track down things which may allocate gc memory lately with accompanying flags to the compiler, which prints a trace of where it may happen.

yoklov 11y ago
I'm always on the look out for improvements to C++, and it's been a while since I looked at D... Hope you don't mind if I ask you a couple questions. Can you still turn off the GC? Lets say I don't like exceptions, and that I don't mind implementing library code on my own, would turning GC off impact anything else? How is the story for deploying executables to mac/win/lin? Is it as easy as C/C++? Also, do you know if anybody's shipped high quality games with it before? It's been a while now, I'd hope so, but I haven't heard of any. Pretty sure no AAA games have used it but maybe some indie?
- CyberShadow 11y ago
  > Can you still turn off the GC? Lets say I don't like exceptions, and that I don't mind implementing library code on my own, would turning GC off impact anything else? You can turn off the GC in the sense that memory allocation will always request more memory from the OS instead of occasionally starting a collect cycle. However, you can alternatively use manual memory management (malloc/free, allocators/RAII on top of that, etc.), which will never trigger the GC. > How is the story for deploying executables to mac/win/lin? Is it as easy as C/C++? Yes. I think for Posix systems, you can optionally link dynamically to the runtime/standard library. > Also, do you know if anybody's shipped high quality games with it before? IIRC, Remedy Games used D for engine scripting on XBox 360. Manu Evans talked about this at DConf 2013. Here's a commercial indie game written in D: http://www.inventivedingo.com/mayhemig http://www.inventivedingo.com/mayhemig
  - yoklov 11y ago
    Well, a couple things about it make me nervous, but CTFE and a not horribly broken compilation model might make it worth trying out next weekend...
- Profan 11y ago
  You can definitely survive without the GC, personally I've gone through eliminating exceptions entirely and implementing my own allocators throughout. There are a few gotchas sometimes, like array literals of certain kinds sometimes allocating when you don't expect them to, but these can usually be sorted. Something which also might bite you, but can be caught with the gc-tracking compiler flag, is the fact that delegate _closures_ use the GC, regular delegates however will not need the GC, one thing to keep in mind. There's quite a bit of info about how the GC impacts things, and how to get by without it around, so I think you'll survive without it's presence. Lately as well, efforts to annotate portions of the standard library which don't use the GC at all with a special annotation @nogc has been underway, which makes it explicit if something can allocate or not (this is transitive, so a @nogc annotated function can only call @nogc annotated functions which can't do any gc allocation in turn).
  - yoklov 11y ago
    I could probably survive not using most of the standard library (I might try to do this anyway to avoid issues with deployment, as I have done in the past in C++). I'm not a huge fan of closures in many cases (if they outlive the scope of their defining function I think it leads to unclear code), so the fact that they might allocate is not a huge deal to me. Array literals silently allocating GCed memory concerns me greatly however... I remember hearing about efforts to remove a lot of the reliance on the GC, and I guess I was hoping that that was further along than it sounds like it is. Still, I'll try not to pass judgement until I try it out on something small. There are a lot of other potential issues unrelated to the GC that would probably be dealbreakers for me.
    - Profan 11y ago
      The array literals problem isn't so bad, the thing is static arrays in D are distinct types, so you'd say int[2] = [1, 2]; which would go on the stack, but doing int[] = [1, 2]; would allocate since it would be a dynamic array then. Good luck with trying it out, you make tradeoffs as with any other language :)

by Profan 11y ago

yoklov 11y ago

I'm always on the look out for improvements to C++, and it's been a while since I looked at D... Hope you don't mind if I ask you a couple questions. Can you still turn off the GC? Lets say I don't like exceptions, and that I don't mind implementing library code on my own, would turning GC off impact anything else? How is the story for deploying executables to mac/win/lin? Is it as easy as C/C++? Also, do you know if anybody's shipped high quality games with it before? It's been a while now, I'd hope so, but I haven't heard of any. Pretty sure no AAA games have used it but maybe some indie?

CyberShadow 11y ago
> Can you still turn off the GC? Lets say I don't like exceptions, and that I don't mind implementing library code on my own, would turning GC off impact anything else? You can turn off the GC in the sense that memory allocation will always request more memory from the OS instead of occasionally starting a collect cycle. However, you can alternatively use manual memory management (malloc/free, allocators/RAII on top of that, etc.), which will never trigger the GC. > How is the story for deploying executables to mac/win/lin? Is it as easy as C/C++? Yes. I think for Posix systems, you can optionally link dynamically to the runtime/standard library. > Also, do you know if anybody's shipped high quality games with it before? IIRC, Remedy Games used D for engine scripting on XBox 360. Manu Evans talked about this at DConf 2013. Here's a commercial indie game written in D: http://www.inventivedingo.com/mayhemig http://www.inventivedingo.com/mayhemig
- yoklov 11y ago
  Well, a couple things about it make me nervous, but CTFE and a not horribly broken compilation model might make it worth trying out next weekend...
Profan 11y ago
You can definitely survive without the GC, personally I've gone through eliminating exceptions entirely and implementing my own allocators throughout. There are a few gotchas sometimes, like array literals of certain kinds sometimes allocating when you don't expect them to, but these can usually be sorted. Something which also might bite you, but can be caught with the gc-tracking compiler flag, is the fact that delegate _closures_ use the GC, regular delegates however will not need the GC, one thing to keep in mind. There's quite a bit of info about how the GC impacts things, and how to get by without it around, so I think you'll survive without it's presence. Lately as well, efforts to annotate portions of the standard library which don't use the GC at all with a special annotation @nogc has been underway, which makes it explicit if something can allocate or not (this is transitive, so a @nogc annotated function can only call @nogc annotated functions which can't do any gc allocation in turn).
- yoklov 11y ago
  I could probably survive not using most of the standard library (I might try to do this anyway to avoid issues with deployment, as I have done in the past in C++). I'm not a huge fan of closures in many cases (if they outlive the scope of their defining function I think it leads to unclear code), so the fact that they might allocate is not a huge deal to me. Array literals silently allocating GCed memory concerns me greatly however... I remember hearing about efforts to remove a lot of the reliance on the GC, and I guess I was hoping that that was further along than it sounds like it is. Still, I'll try not to pass judgement until I try it out on something small. There are a lot of other potential issues unrelated to the GC that would probably be dealbreakers for me.
  - Profan 11y ago
    The array literals problem isn't so bad, the thing is static arrays in D are distinct types, so you'd say int[2] = [1, 2]; which would go on the stack, but doing int[] = [1, 2]; would allocate since it would be a dynamic array then. Good luck with trying it out, you make tradeoffs as with any other language :)