Managed C++ for Game Programming?

I've begun to rewrite my engine, using Windows Forms for the UI, which uses Managed C++/CLR/.NET (i'm not really sure which is the appropriate name; I don't really know the difference).

I'm wondering though, if MC++ is suitable to code the engine framework in. Would it cause the engine to be slower? Are there any advantages to MC++? Or would I be better off just sticking with standard C++ for the engine framework, and leaving the Managed stuff to the UI?

Sorry for the many questions at once, but I really don't get what this Managed C++/CLR stuff is all about, and certainly not how it would affect game programming.

Thanks.

Stroustrup is not very happy about it.

Quote:

---

but I really don't get what this Managed C++/CLR stuff is all about, and certainly not how it would affect game programming.

---

It's about Microsoft. No, it's not good.

Quote:

---

Originally Posted by psychopath

I'm wondering though, if MC++ is suitable to code the engine framework in. Would it cause the engine to be slower? Are there any advantages to MC++? Or would I be better off just sticking with standard C++ for the engine framework, and leaving the Managed stuff to the UI?

---

Managed C++ could be suitable to code a game engine framework with if all of your engine code is unmanaged C++ and you're only using the .NET extensions for the UI like you say. The unmanaged code will be compiled into actual machine instructions just like C++ would so it may not be very much slower if you know what you're doing.

IMHO I'd stay away from developing a game engine with Managed C++ though, because the relationship between managed and unmanaged code is pretty awkward and I can imagine it turning into a debugger's nightmare real fast.

And just a personal note here, but I've never come across a good example of Managed C++ being useful enough to justify its existence. :p

I actually decided to go with C++/CLI for everything (UI and engine) since I first posted this. So far, i've noticed no slowdown (as long as I run the exe in release mode). I can always run NGen on the exe if I need to.

I did make an attempt at just keeping the windows forms related stuff managed, and the rest native, but that turned out to be very difficult to keep up, due to the incompatible types, and conversion and marshaling usually doesn't work properly for this. The main problem I had though, was OpenGL. In order to run OpenGL in a control in the UI, I needed to use OpenGL bindings for .NET (I used the Tao Framework for this, if you're interested), meaning that my engines OpenGL driver would need to be managed, and this of course, would not mix very well at all with native code. For example, the managed version of glVertex3fv() takes a managed array; if I coded the rest of the engine in native C++, the engine would probably try to pass this function a native array. Converting this would be very slow, perhaps moreso than just using C++/CLI for everything, and avoiding ugly conversions.

The only code I have kept native, is in some file loaders which depend on knowing the size of a struct at compile time.