Can garbage collection coexist with explicit memory management?

Question

For example, say one was to include a 'delete' keyword in C# 4. Would it be possible to guarantee that you'd never have wild pointers, but still be able to rely on the garbage collecter, due to the reference-based system?

The only way I could see it possibly happening is if instead of references to memory locations, a reference would be an index to a table of pointers to actual objects. However, I'm sure that there'd be some condition where that would break, and it'd be possible to break type safety/have dangling pointers.

EDIT: I'm not talking about just .net. I was just using C# as an example.

Answer 1

You can - kind of: make your object disposable, and then dispose it yourself.

A manual delete is unlikely to improve memory performance in a managed environment. It might help with unmanaged ressources, what dispose is all about.

I'd rather have implementing and consuming Disposable objects made easier. I have no consistent, complete idea how this should look like, but managing unmanaged ressources is a verbose pain under .NET.

---

An idea for implementing delete: delete tags an object for manual deletion. At the next garbage collection cycle, the object is removed and all references to it are set to null.

It sounds cool at first (at least to me), but I doubt it would be useful. This isn't particulary safe, either - e.g. another thread might be busy executing a member method of that object, such an methods needs to throw e.g. when accessing object data.

Answer 2

With garbage collection, as long as you have a referenced reference to the object, it stays alive. With manual delete you can't guarantee that.

Example (pseudocode):

obj1 = new instance;
obj2 = obj1;

// 

delete obj2;
// obj1 now references the twilightzone.

Just to be short, combining manual memory management with garbage collection defeats the purpose of GC. Besides, why bother? And if you really want to have control, use C++ and not C#. ;-).