That’s an urban legend 
2 Likes
Well you don’t need to believe me. There’s reality. Look at how much of the essential real world software is written in C/C++. What percentage of that really leaks?
There’s a reason C++ is unbeatable and no amounts or Rusts can replace it. It’s the irresistible lure of walking on the edge of naked pointers. Even if one never uses them, just knowing they are there, free to be plucked from the meadows of memory at any time - warms the heart.
7 Likes
Oh you are being serious .. 
A lot , which is why C#’s Garbage collection exists.
Godot has ref counting (in effect GC, just in near real time), Unreal (written in C++) , has its own Garbage collection, and the same goes for Unity as well.
Its almost like if you are not careful with C++ you end up with memory leaks. Everything has to be unallocated in memory from C++ manually after its no longer used. Thats fine for say a 2000 line application, but when you are talking about a game that could have hundreds of thousands of lines if not millions then its very easy to do.
1 Like
Not entirely. But then again, not entirely not
You can end up with memory leaks anywhere if you’re “not careful”. Even in GDScript.
C++ is about performance. If you need to feel “safe” with the core language and are willing to sacrifice performance for that, then sure, stay away from C++.
The thing is, you can play any game in C++, including garbage collection game. It’s designed for versatility and paradigm agnosticism. The fact that the core language doesn’t manage memory doesn’t mean you can’t manage memory, as noted by your own examples. You don’t have to make leaks but you can if you want. That’s the power I like to have. But as they say - with power comes responsibility.
2 Likes
I worked on early MMO back in the late 90s. During testing, every person who logged in made the game run slower. We couldn’t definitively tell the producer that it wasn’t working, so he shipped it to production. Now it’s important to know that we were based in the US, and most of the active players were in Europe. We put the game up and went home at 5pm. (Ah, the early internet with no three nines of guaranteed uptime.)
Every player logged in caused a separate memory leak on the server. Hence the slowdowns we were seeing. Every time the player count hit 80, (which took 10 to 20 minutes) the memory on the server would be maxed out. The server would core dump and restart. Then people could log in again, and the cycle would happen again - all night long.
C++ memory leaks are insidious. They are also why higher level languages exist. Personally, I do not miss dealing with memory management or dereferencing pointers.
3 Likes
You people act like there are no smart pointers in stl . Also you don’t ever have to use a pointer in C++.
1 Like
Yeah, I’d only endure it for performance. I’d never opt for C# as a replacement though. Its verbosity gives me rashes.
5 Likes
Because those were introduced in 2014 in C++ 14, and I stopped using C++ a few years before that.
I used to enjoy dereferencing pointers. It was a fun game. But it got old.
1 Like
With a circualr reference , yes its possible, but not as easy.
I think we can have both, if you need bleeding edge , then sure. But most people who are using Godot don’t.
In theory, going back to the original question posed you can with GD Script as well, it will just be a lot slower for certain games.
But we seem to be in a circular discussion now, and if we are not careful the topic is going to leak memory all over the place.
4 Likes
func _exit_tree():
Node.new()
^ That just leaked about a kilobyte of memory. Easy as pie.
It’s actually not all that easy to cause leaks in modern C++, unless you intend to or are completely clueless.
At the end of the day, the fact remains that all relevant modern game engines (including, well, Godot) are written in C++. And those things certainly have more than 2000 lines of code. You gotta ask yourself why the guys who wrote them chose that leak-factory over something like C#. Do they know something we don’t? 
4 Likes
I just laughed so hard when I read that.
I’ve had one memory leak in Godot. It was when I was trying to make a sound effect manager very early on. I wanted to just store the AudioStream with the object and not an AudioStreamPlayer to optimize memory. It turned out I was spawning AudioStremPlayers as needed, but never freeing them, so they just clogged up my tree. Oops.
I have since learned that using AudioStreamPlayers attached to objects is better in most cases for a myriad of reasons. It’s especially important if you want to use AudioStreamPlayer2D and AudioStreamPlayer3D objects. I still use a sound manager, but only to maintain volume levels, and two music players for game music and pause music.
4 Likes
Yeah but moderne C++ idioms are just too verbose and cryptic 
Give me C and Lua, and I was a happy gamedev/code primate
Cheers !
2 Likes
After all, Godot and GDScript are games played in C++ when you get down to it, to reuse normalized imagery without much refactoring
3 Likes
2 Likes
But who would do that
Everyone should be using Assembler anyway.
3 Likes
They also ALL have some sort of garbage collection process as well though.
1 Like
Probably the same people who would leak a C++ program using dangling pointers. You said it’s hard to leak in GDScript. I only demonstrated it technically isn’t. Your logic can equally be applied to C++ too - It’s technically easy to leak, but who would do that?
Ah the old assembly strawman. What point are you trying to argue here? Re read my couple first posts in this thread. I’m always for doing everything at the highest and most convenient possible level. Unfortunately, performance doesn’t care for convenience.
Yeah, written in C++
Looks like it’s possible to do garbage collection in C++. Who would’ve thunk that?
C++ has come a long way since the days of new/delete, but some (many?) people seem to be mentally stuck in that era.
1 Like
To be fair, I’m stuck in the C era.
1 Like