I have a plan.. I really DO

wjoe none at example.com
Thu Jul 5 14:04:18 UTC 2018


On Wednesday, 4 July 2018 at 19:29:55 UTC, Ecstatic Coder wrote:
> First, to be clear, I mainly use D as a scripting language for 
> file processing, and for this use case, having a GC is a 
> blessing.

This is a non issue and a GC doesn't matter at all in this case. 
You could allocate all you wanted and never free and as long as 
there's enough memory to finish the script you couldn't tell the 
difference. Once a script or program is done the OS reclaims all 
memory.

But memory leaks in software, running in some kind of main loop, 
become real performance bottlenecks eventually and a time sink to 
debug.

> You say that garbage collection is not a real problem for game 
> development.

No, what I'm saying is that I've hadn't had any issues with the 
GC so far and that I don't expect any.
I'm also saying that I keep hearing this argument against using D 
but it was never backed up by anthing substantial so it sounds 
like an excuse by folks who never really considered D in the 
first place.

Like, what does it matter if a collection cycle is triggered 
during a loading screen ?
Performance aware C++ folks do have to do resource management at 
some point, too, and that's not free either and is usually done 
while the loading screen is displayed.

> For instance, have you read Unity's own official 
> recommandations on how to overcome this problem ?

No, I haven't.
It probably boils down to pre-allocation, object pools, reusing 
objects, don't allocate in a loop, caching data, be mindful of 
what you do and when and how, etc, etc.

Which would be good advice for game development in general and 
I'd do exactly that in C/C++, or any non-GC'd language, too.


> And about developing video games in C++, actually most studios 
> use orthodox C++. This means no exceptions, no RTTI, few 
> virtual methods, fast lightweight smart pointers and 
> collections, etc.

They could get that with -betterC which also does not use a GC.


> And about the scripting language, it's not my fault if some 
> game engine developers don't care for the performance or GC 
> issues when adding a scripting language to their game engine.

Never said it was your fault, just pointed out the fact that it's 
a very common occurance.

> So, as I said, those who use C++ or Rust because D's GC is a 
> problem for them, won't probably use D in its current state.

Or any other language tagged GC for that matter, except maybe LUA.

Nobody and nothing forces anyone to use the GC or features which 
use it. Just go ahead and  manage your memory manually. They will 
not be using features like dynamic arrays, the standard library, 
and such but that's not a loss since they'd roll their own, more 
performant implementations, anyways.

But I'm convinced that they wouldn't consider D - even if there 
was a GC-free Phobos.
They would find the next excuse.

Those who are willing find solutions, those who are not find 
excuses.





More information about the Digitalmars-d-announce mailing list