Master thesis

[Dgame via Digitalmars-d]

On Saturday, 1 July 2017 at 21:00:14 UTC, Ecstatic Coder wrote:
> Whatever the object oriented language you use, you can keep 
> exactly the same global game architecture, using more or less 
> the same classes for your game subsystems and gameplay elements.
>
> Therefore, as an old game industry veteran, I confirm what you 
> already know, which is that it's all about memory allocation, 
> access and deallocation when comparing a game made in C++, D or 
> Rust.
>
> I'm not saying that other matters are not important, but many 
> game development directors apply Bertrand Meyer's architectural 
> advices (design by contract with pre/post condition assertions, 
> etc) since the early nineties, so there is not much difference 
> between a C++ game and a D/Rust game in this area.
>
>
> So all that remains in the end are just concurrency and 
> memory-related features, like immutable data, array memory 
> slicing, automatic array bound and null pointer checking, 
> object destruction and deallocation through variable scope and 
> garbage collection, etc.
>
> This of course includes interfacing with C/C++, i.e. managing 
> the memory and lifecycle of C/C++ structs/objects from D or 
> Rust.
>
> With D, my biggest concern was about avoiding the application 
> thread to freeze during a GC, while C++ and Rust can completely 
> ignore this problem.
>
> IMHO just these last points could already explain why Rust and 
> C++ still remain preferred to D for game development...

That's a good statement which I found very often recently. Maybe 
I should change my main focus from architecture to 
software-engineering per se...
Maybe an comparison between different software-products (one in 
an insecure  and one in a secure programming language) to show 
the difference and potential vulnerabilities.