Why do you hate C++ so much?

Then stick with C++ it's the de facto standard for game programming and will be for the foreseeable future

thanks user

Attached: 1541739016408.png (2263x1599, 566K)

... Why would you do that? D is better but C++ is far more popular.

D is actually a deadlang. There is no reason to use that shit.
Nobody wants some garbage collected shit pretending it's a system language.
I'm not saying anything about the actual quality of the language, but Go completely dominates the niche that D could have hoped to have.

>Nobody wants some garbage collected shit pretending it's a system language.

You have no idea what you're on about. The GC issue has been basically solved, as the language now offers plenty of facilities for manual memory management and lets you completely strip the garbage collector out from binaries if you want.

> Go completely dominates the niche that D could have hoped to have

Ok, you're just proving you have no idea what you're talking about. Go has nothing on D. I'm not saying this as a language fanboy, but the flexibility that D offers dwarfs Go to the point of making it redundant for most purposes. Go's niche is as a fast networking language, but it has no real intention of being anything more than that and absolutely cripples itself by not even having type generics.

>The GC issue has been basically solved, as the language now offers plenty of facilities for manual memory management and lets you completely strip the garbage collector out from binaries if you want
Now you can't use any libraries that happen to need a GC. Great.
Not to mention this feature was added literally years after people stopped giving a flying fuck about D.

pic related killed me

If this were a real world case const would be better. Define globally defines things and if FIZZ or BUZZ is defined anywhere else in the code it would cause a c preprocessor error unless it is immediately undefined. Const would be locally scoped by the c compiler (c preprocessor would ignore it) and would compile to the same code.

>putting defines in the middle of the function like they are actual variables
please don't do this
t. actual C developer

>we took a GC'd language and got rid of the GC, therefore we fixed the GC
that's not a solution to the problem. What if I have dependencies that rely on the GC? If I'm managing the heap manually, why not just use C and get the performance and runtime overhead advantages?

But you can though. You can freely mix GC and non GC code, and guarantee that the GC won't run during code you don't want it to. The strip out feature is just there so that you can create minimal binaries if you want.

>Not to mention this feature was added literally years after people stopped giving a flying fuck about D.

Now you do have a point. There is no *hype* behind D. There never really was, because it started out as a humble "C++ that doesn't suck as much as C++", then only became the monster it is now after development was overhauled with D2.0

This is an issue with the ecosystem, a serious one no doubt, but it doesn't stop it from being the best currently existing practical alternative to C++.

I don't like c or c++ because they are and will always be trash.

c+ is for patricians
c++ is for basedboys

>You can freely mix GC and non GC code
this is such an awkward comprimise
either commit to making a GCed language or dont
dont try to do both

Nobody who used C++ was missing a GC. Nobody who used C++ wanted half of its features to be locked behind a GC, either.

>Nobody who used C++ was missing a GC. Nobody who used C++ wanted half of its features to be locked behind a GC, either.
Ah yes, that's why Unreal implements its own GC; Unity not only that, but a full C# runtime; and Godot it's own interpreted python-like scripting lang.

Different languages have different roles
The point is nobody wanted GCed C++

Those three are applications written in C++: the point being that bare C++ was deemed not useful enough without a GC (or embedded langs with a GC) for their domains.

Pluggable scripting langs aren't the same thing.

You're drawing an illogical comparsion here, the language the internal engine is written in is irrelevant because it's different to the user-facing script system

That would be a risky move.
If you 'just' want to make games consider C# and a game engine like unity.

But this approach has real advantages. You're only saying this because you're used to languages being either one or the other, and so a hybrid that can serve multiple roles just seems unnecessary. Having this model means the freedom of great expressive power when latency isn't an immediate concern, along with fast, consistent performance when it is.

As points out, plenty of projects use 'scripting' languages to make up for the expressive limitations of C++ and its compilation and memory models. The thing is, D lacks exactly those issues and so the need to add extra languages on top of core engine code basically disappears, as any 'script' can be compiled and linked in dynamically at runtime in D itself. As such it can avoid the awkwardness of having to use multiple languages in the first place, which previously wasn't even thought of as a problem that could be solved without serious compromise.

The point is that the whole motivation of the 'user-facing script system' is due to unnecessary limitations of the engine language that can be done away with as long as you allow freedom in how memory management is approached.

scripts aren't making up for the limitations of C++
I write a game engine in a language that isn't C++ and I still use scripts because of things like dynamic typing and the portability of running in a VM which you certainly don't want in your base language