The power of .NET without the garbage collection?

Question

I love C# because the powerful features of the .NET framework make it so easy to develop for Windows. However I also love standard C++ primarily because it gives me fine-tuned control over memory management. Is there a way to have the best of both worlds? Are there C++ libraries that can compete with the rich set of libraries in the .NET framework? Or is there a way to manually deallocate memory in one of the .NET languages that I've never used? OR is it possible to use a .NET dll in a standard C++ application? I know, I'm really stretching here, but I believe in magic.

Answer 1

Have you looked at Boost?

Alternatively, you can use "C++/CLI" (a.k.a. managed C++, a.k.a. C++.NET); code written in this language can call into .NET APIs and can also manually manage memory via traditional Win32 APIs like HeapAlloc/HeapFree. In my experience, though, this language is most frequently used for writing "glue code", and not for building applications from the ground up.

Answer 2

You can also 'pin' segments of code in C#, if you really want to have explicit access pointers and such (from MSDN):

unsafe static void TestMethod()
{
  // assume class Point { public int x, y; }
  // pt is a managed variable, subject to garbage collection.
  Point pt = new Point();

  // Using fixed allows the address of pt members to be
  // taken, and "pins" pt so it isn't relocated.

  fixed (int* p = &pt.x)
  {
      *p = 1;
  }        
}

But really, I think you're better off determining why specifically you're looking to manage memory yourself--most developers I know at this point would rather focus on the actual design and construction of systems, rather than worrying about deallocating chunks of memory. There are other good suggestions here, such as Boost (though honestly, if you've got the cajones to announce you're better than the GC, you're probably already aware of Boost), Qt, and .NET bridging (hell, you can host the CLR in an unmanaged process, if you like), but I suspect that for the few places where it actually may behoove you to manage memory yourself, you'll be much better off constraining them to a VC++ project referenced by the rest of your solution.

Answer 3

Here's one reason why you would need no-GC .NET; developing XNA games on wp7 or coming win8 tablets. If you're not careful about object allocation, GC really creates a choppy game experience because it kicks in periodically. There are ways around it by doing object pooling, etc. However, you don't have control on all objects that are created. So there's no guarantee objects will go through same pooling mechanism. I can imagine a special mode of GC which suspends collection until you tell it to continue. In the no-GC mode, it would not do any collection, but it would reuse memory that's released by objects rather than waiting for collection first. Pretty much like C++ memory manager. It could do this by checking if an object's memory area should be made available right away. I'm sure it'll be harder to implement it than what I'm describing here, but it would be worth having this feature so that .NET developers are empowered in realtime development like games.