I have a plan.. I really DO

wjoe none at example.com
Wed Jul 4 18:05:15 UTC 2018


On Wednesday, 4 July 2018 at 08:50:57 UTC, Ecstatic Coder wrote:
> But indeed, being able use D in a GC-free environment (like C++ 
> and Rust do) would be something many people may NEED, for 
> instance to be able to EASILY use D for soft-realtime 
> applications like games.

This has to be the no. 1 excuse.


Why is C++ the language of choice currently? My bet is 
productivity and economic concerns. Amongst other things the 
productivity gain from resource management via constructor and 
destructor. Which solves like 75% of the headaches of manual 
resource management and goto nightmares.

Back in the day when C was used to make games, the excuse not to 
use C++ was vtable, exception and RTTI overhead. Now it's called 
the bare metal best performance language which everything and 
their grandma is measured against. This C++ overhead didn't make 
C any slower or C++ any faster than C but it made C++ superior in 
productivity.

This was around 2002/03, and C++, at the time, some 23+ years old.

Games have been made with GC'd languages, 3D games, even. And 
successfully, too.
Minecraft, a very successful one, comes to mind, which is or at 
least was made in Java.
Plenty of games are made in C#, too.

My bet, again, would be productivity and economic concerns. The 
countless hours wasted on debugging memory leaks and cyclic 
dependencies are better spent making the actual game/software.
And smart pointers introduce overhead of their own which makes 
them inferior to C's bare metal raw pointer performance - or GC'd 
pointers for that matter. The culprit being the collection cycle.

The best thing about this whole argument, however, is the claim 
for GC no can do and with the next breath they pull LUA into 
their games. A scripting language that brings a VM, GC and 
extraordinarily inflated loading times when the scripts are 
compiled to byte code at the end user's PC which make C64 loading 
times shine.
The reasoning probably being productivity again and C++'s lunch 
break compile times.

Using the D compiler as a library, instead of LUA, D code could 
be used for 'scripting', as well, and compiled to native machine 
code. In a snap.

I have no metrics between any AAA game engine and their port to D 
but I do know that I wrote a sound/music player library in Java, 
which folks like you claim impossible because GC, never bothered 
with GC and had no performance issues whatsoever - and I don't 
expect any porting it to D.

And there is EASTL. A STL made by Electronic Arts. Because the 
standard implementation shipped with the compiler is too slow ? 
Even though written by C++ wizards ?


Slow code is slow and allocating memory in a tight loop is a huge 
performance killer - regardless of language.

Also, why do you feel like a GC is inacceptable for games but 
doesn't matter for your file handling program? Handling dozens, 
maybe thousands, of files sounds like an awful lot of memory 
management involved and whether a e.g. grep takes 15 seconds to 
do it's job or under 1 matters not?

Nothing forces anyone to use the GC, memory can be managed 
manually via malloc/free and you get to do it with scope 
statements/nested functions which makes it nicer than in C. You 
could also implement shared/weak ptr stuff in D - warts and all.
If you need a GC free standard library, I believe there is an 
ongoing effort -or several- at code.dlang.org and probably other 
places.


You said do this and that, GC, etc. to motivate C++ folks to come 
to D. I say it's an excuse not to use D and no matter the effort 
of advertising, a GC free phobos, etc. on part of the D-Lang 
Foundation and contributors would make these folks switch. They 
would simply find a different excuse.

And where's the usefulness of toy examples like 2 line web 
servers which essentially do nothing?
And how is that helping with getting attention from the game devs 
?
Putting on the front page a 12 line maze game which can be 
imported from the standard library? Not using the GC?


More information about the Digitalmars-d-announce mailing list