5 ms·

> I really wish D as better C worked better in that realm, but it's missing a few crucial things. Such as? We are always looking for for things that get in the

> I really wish D as better C worked better in that realm, but it's missing a few crucial things. Such as? We are always looking for for things that get in the way of use.

Bekwnn 8y ago
Under "unavailable features" https://dlang.org/spec/betterc.html#consequences https://dlang.org/spec/betterc.html#consequences 3, 4, and 5 are all pretty sore points. 2 would be as well if it weren't extremely likely that for any game you create roll some sort of reflection system. It would be a sore spot for small projects. 3 - No access to classes and polymorphism is a bit of a downer. Although I'm a big believer of data-oriented design, I think there are still many cases where modelling things as objects is the best way to go, especially for things like scene actors and game objects. 4 - No built in threading (core.thread) puts a hamper on any sort of distributed updating or performance optimizations you'd want to do. I'd imagine the workaround is external multi-threaded dlls or something, but it sounds like a pain to manage and deal with in a workflow. 5 - No dynamic arrays. This container is used abundantly in game development. It shows up 5 or more times for every heap/stack/queue. This may not be an issue if you want to write a special memory environment and your own containers, which is common in game development, but not having access to a standard one certainly hurts when it comes to smaller projects or graphics programming experiments. I may be somewhat off base here since what happened is that I read about those being missing and decided not to try it. Another note is that a big thing I'm looking for is massively improved compile times, which is one of the biggest things Jai looks to have over C++ in addition to its compiler hooks and #run.
- FeepingCreature 8y ago
  It seems to me like you should just be using D, not "Better C-style D"? All those features are not in BetterC because they need a garbage collector, but they are of course in D proper. For smaller projects, I'd recommend just ignoring the GC until you run into actual issues with it, then optimizing for the specific issues.
  - comex 8y ago
    That's easy to say, but as long as C++ and other languages can do those things without a garbage collector, D seems somewhat less attractive. (I'm not the OP but I've had a similar experience with D.)
    - WalterBright 8y ago
      You can do all of them without a garbage collector - you just have explicitly manage the memory yourself.
  - makomk 8y ago
    As I understand it, garbage collection is kind of a non-starter for games programming because it leads to unpredictable pauses in what should be a low-latency, interactive application.
    - bausshf 8y ago
      It is optional however and you can use custom allocators to get around it.
    - p0nce 8y ago
      Infognition has found that if you keep the D GC heap under 100k the max pauses will be about 1 ms. The means to reduce GC usage have only grown more diverse in recent years: - std.experimental.allocator - @nogc to ensure, well, no GC usage - various things built on placement new (`emplace`) - GC profiling with -profile=gc, will display number of allocations and size None of this existed when people were already making high-performance systems with D...
    - qznc 8y ago
      You can put the low-latency stuff in a non-gc thread which will not be interrupted [0] and still use the convenient garbage collector for the rest. [0] https://p0nce.github.io/d-idioms/#The-impossible-real-time-thread https://p0nce.github.io/d-idioms/#The-impossible-real-time-t...
    - 8y ago
- z92 8y ago
  These "unavailable features" are available in D. But NOT when you compile with a specific switch on.
- atilaneves 8y ago
  That page should be updated. I was suspicious about #3 since classes in D don't necessarily need the GC. For starters D supports C++ classes, so this works: https://gist.github.com/atilaneves/b69ed0399efac21bb7a977afdfedee8f https://gist.github.com/atilaneves/b69ed0399efac21bb7a977afd... I used `scope` with `new` to allocate on the stack, but `emplace` should just work as well to "placement new" a class in malloc'ed memory. #4 is annoying but one could always use the OS threading API. It's doable to write a library solution to do that akin to boost or Qt before C++11. You do it once and it's there. #5 No dynamic arrays are also annoying. But... writing a clone of std::vector isn't hard, and there's a unique array in my automem library that _should_ be usable in betterC (but I haven't checked): https://github.com/atilaneves/automem/blob/master/source/automem/unique_array.d https://github.com/atilaneves/automem/blob/master/source/aut... > Another note is that a big thing I'm looking for is massively improved compile times You get that with D.
- p0nce 8y ago
  I have a smallish D game on Steam and trust me, you can absolutely use the D runtime instead of -betterC. -betterC is a work in progress and not representative of D. You will say that you don't want a GC but in reality the GC can be optimized as much as you wan't, and in the mean time you'll get precious _developement time_ to optimize further. If you can afford the D runtime by all means take it ; for some products I'm doing without the D runtime, and the surprise was that it did't make things any faster _at all_ without the runtime (we did it for other reasons). The only real gain is memory consumption of GC vs manual and that is achievable without going through extreme coercitive measures like -betterC.
- WalterBright 8y ago
  > 3,4,5 Those rely on the garbage collector. If you are willing to do C style memory management, they are all available with betterC.

> I really wish D as better C worked better in that realm, but it's missing a few crucial things. Such as? We are always looking for for things that get in the way of use.

Bekwnn 8y ago

Under "unavailable features" https://dlang.org/spec/betterc.html#consequences https://dlang.org/spec/betterc.html#consequences 3, 4, and 5 are all pretty sore points. 2 would be as well if it weren't extremely likely that for any game you create roll some sort of reflection system. It would be a sore spot for small projects. 3 - No access to classes and polymorphism is a bit of a downer. Although I'm a big believer of data-oriented design, I think there are still many cases where modelling things as objects is the best way to go, especially for things like scene actors and game objects. 4 - No built in threading (core.thread) puts a hamper on any sort of distributed updating or performance optimizations you'd want to do. I'd imagine the workaround is external multi-threaded dlls or something, but it sounds like a pain to manage and deal with in a workflow. 5 - No dynamic arrays. This container is used abundantly in game development. It shows up 5 or more times for every heap/stack/queue. This may not be an issue if you want to write a special memory environment and your own containers, which is common in game development, but not having access to a standard one certainly hurts when it comes to smaller projects or graphics programming experiments. I may be somewhat off base here since what happened is that I read about those being missing and decided not to try it. Another note is that a big thing I'm looking for is massively improved compile times, which is one of the biggest things Jai looks to have over C++ in addition to its compiler hooks and #run.

FeepingCreature 8y ago
It seems to me like you should just be using D, not "Better C-style D"? All those features are not in BetterC because they need a garbage collector, but they are of course in D proper. For smaller projects, I'd recommend just ignoring the GC until you run into actual issues with it, then optimizing for the specific issues.
- comex 8y ago
  That's easy to say, but as long as C++ and other languages can do those things without a garbage collector, D seems somewhat less attractive. (I'm not the OP but I've had a similar experience with D.)
  - WalterBright 8y ago
    You can do all of them without a garbage collector - you just have explicitly manage the memory yourself.
- makomk 8y ago
  As I understand it, garbage collection is kind of a non-starter for games programming because it leads to unpredictable pauses in what should be a low-latency, interactive application.
  - bausshf 8y ago
    It is optional however and you can use custom allocators to get around it.
  - p0nce 8y ago
    Infognition has found that if you keep the D GC heap under 100k the max pauses will be about 1 ms. The means to reduce GC usage have only grown more diverse in recent years: - std.experimental.allocator - @nogc to ensure, well, no GC usage - various things built on placement new (`emplace`) - GC profiling with -profile=gc, will display number of allocations and size None of this existed when people were already making high-performance systems with D...
  - qznc 8y ago
    You can put the low-latency stuff in a non-gc thread which will not be interrupted [0] and still use the convenient garbage collector for the rest. [0] https://p0nce.github.io/d-idioms/#The-impossible-real-time-thread https://p0nce.github.io/d-idioms/#The-impossible-real-time-t...
  - 8y ago
z92 8y ago
These "unavailable features" are available in D. But NOT when you compile with a specific switch on.
atilaneves 8y ago
That page should be updated. I was suspicious about #3 since classes in D don't necessarily need the GC. For starters D supports C++ classes, so this works: https://gist.github.com/atilaneves/b69ed0399efac21bb7a977afdfedee8f https://gist.github.com/atilaneves/b69ed0399efac21bb7a977afd... I used `scope` with `new` to allocate on the stack, but `emplace` should just work as well to "placement new" a class in malloc'ed memory. #4 is annoying but one could always use the OS threading API. It's doable to write a library solution to do that akin to boost or Qt before C++11. You do it once and it's there. #5 No dynamic arrays are also annoying. But... writing a clone of std::vector isn't hard, and there's a unique array in my automem library that _should_ be usable in betterC (but I haven't checked): https://github.com/atilaneves/automem/blob/master/source/automem/unique_array.d https://github.com/atilaneves/automem/blob/master/source/aut... > Another note is that a big thing I'm looking for is massively improved compile times You get that with D.
p0nce 8y ago
I have a smallish D game on Steam and trust me, you can absolutely use the D runtime instead of -betterC. -betterC is a work in progress and not representative of D. You will say that you don't want a GC but in reality the GC can be optimized as much as you wan't, and in the mean time you'll get precious _developement time_ to optimize further. If you can afford the D runtime by all means take it ; for some products I'm doing without the D runtime, and the surprise was that it did't make things any faster _at all_ without the runtime (we did it for other reasons). The only real gain is memory consumption of GC vs manual and that is achievable without going through extreme coercitive measures like -betterC.
WalterBright 8y ago
> 3,4,5 Those rely on the garbage collector. If you are willing to do C style memory management, they are all available with betterC.