One thing that hasn't been considered in all this GC discussion is that the GC only knows about memory.

That's it.

The C++ "RAII" idiom actually can clean up any resource immediately. And this is incredibly important. It is, in fact, so important that .NET has the IDisposable idiom to perform RAII-like tasks in its GC world.

Yep, and that means you get scoped RAII the same as C++, so I don't really see why that's an issue?

Because I have to write a huge amount of boilerplate code, and write it perfectly, knowing whether other "garbage collected" pointers I'm using have been cleaned up or not, just do implement something I get for "free" in C++.

I have to actively work against the GC because the GC is not designed for this.

And they don't do anything for you with non-memory resources.

Not entirely true. Consider the following class

public class Resource<T> : IDisposable
    where T : class, new()
{
    private readonly string _id;
    private T _resource;

    public Resource(string id)
    {
        _id = id;
        _resource = new T();
        Console.WriteLine("{0} acquired", _id);
    }

    public void Dispose()
    {
        if (_resource != null)
        {
            _resource = null;
            Console.WriteLine("{0} released", _id);
        }
    }
        
    ~Resource()
    {
        Dispose();
    }
}

In this case, the resource can either be manually scoped (i.e. using) or if we're not concerned about when the Resource is released, we can let the GC take care of it

new Resource<object>("global");
using (new Resource<object>("local"))
{
               
}

// output 
global acquired
local acquired
local released
global released

Again, the GC only handles memory. It has no sense of urgency with how needed another resource is because it can only see memory pressure, not active file system requests (for example). Also, you have actually implemented it incorrectly. You do not handle cleanup of managed resources, and you do not tell the GC to suppress the finalizer when it is disposed (reference).

The sheer number of people asking how to implement IDisposable properly show how much of a hack it is.

I'm not saying you should avoid C# because of this. But it is a major downside to the way it (and other GC languages) are designed that languages like C++ just handle far better.

Oh, and I almost forgot. The IDisposable pattern requires your user to be aware that you use it, and to handle it correctly on their end. Or even better - they have to figure out how to implement the disposable pattern if they store an instance of your class in their own. Both things that, again, C++ gives you automatically with its stack and RAII wrappers for heap objects.

I agree with a hell of a lot of what you have said in this thread, but I think we are missing the point a little.

Yes you have to think of the GC when you write your code, it's really important, but if you screw up, then your game runs slowly because the GC is running all the time.

If you screw up in c++, the game crashes.

Now I personally prefer the game to crash, it MAKES you fix the problem, but for a newb starting out the game running slowly is probably a better idea.

I spend a hell of a lot of my working week finding memory issues. They usually come down to some idiot grabbing a reference to something and failing to release it at the right time. Simple fix when I do find it.

Hell of a job to find it.

One line of code missing in several million LOC's...... whimper.

I also have to deal with several completely different memory managers, fast ones, safe ones, ones that defrag themselves, ones that were written in 1991, even one called a Two Level Segregated Fit memory allocator,

GC is looking rather nice at the moment.