MC++ vs. C#

Quote:

Let me conclude by saying that time is not an issue. If C# is ultimately the better way to go, I AM willing to recoding 200 source code files. Time is no issue. End performance is. I don't want to recode 200 files into C# and then, at the end of the process, discover I got better performance from C++.

Now I am not trying to make a point over which is better, but if you already have C++ source files, why not just use C++ again? If you already have the code, why bother converting it to some other language? Why even bother going to MC++ if you don't have to? MC++ and C# are good if you are just starting to write your program, but if it is already written, why bother converting?

C++ has supposedly faster speed, while MC++ and C# are easier to write programs in. You won't get any advantage by converting to use the .NET framework, which by design will work at least a tiny bit slower and will require that much more hassle to install on the user's system.

What I am trying to say I guess is that you already have all that work done. Why bother converting?

Quote:

Original post by xpnctoc [...]Trust me, I would not keep arrays of multiple data types if I had another conceivable alternative[...]

Polymorphism will likely handle the cases you need, and C++ handles it rather well.

As far as the rest of your post, if by MC++ you mean managed C++, then my suggestion is that you go with C#. Managed C++ is little more than a hack to bridge the gap between the popular C++ and the .Net Framework. C#, on the other hand, was designed from the ground up to work with and take advantage of the capabilities of .Net. I seriously doubt that you'll have any performance problems with either language that are caused by the language, the compiler, or the framework, that don't have some simple workaround.

I don't have much experience with either language, though, and you didn't state why you're switching to the .net framework from normal C++ (supposing that is what MC++ means). If it's for nothing more than hoping the garbage collector will make up for sloppy use of pointers (or references), well, that isn't the case. It will make allocation and deallocation of memory easier, but won't magically make errors based on pointer/reference logic go away.

Quote:

Original post by ussnewjersey4 What I am trying to say I guess is that you already have all that work done. Why bother converting?

It just seems that C# is a little cleaner. For example, not having to deal with header files. And, as I said before, I suspect the memory management side of .NET would help out the last couple of bugs I've experienced. I mentioned pointer errors before. While I haven't pinpointed the cause, I'm 99% sure it's somewhere in the massive amount of alloc/dealloc I perform, rather than an actual error in reference logic. You all have to trust me on that one. Explaining how I've arrived at that conclusion would be too time consuming.

As this is a side-project for me, it has kind of morphed over time. So I'm already planning on some level of rewrite -- "refactoring" -- just to clean up and reogranize before I add the next set of new features to the game. I was just trying to determine if I should make an all-out conversion in the process. Then again, maybe in the refactoring I'll finally find the cause of those pointer errors.

Perhaps a mix of things is in order -- keeping the graphics and physics in "IJW" unmanaged C++, and using managed C++ to handle some of the low priority work where the .NET classes would be really useful.

In the interest of clarity, MC++ is deprecated, it is now C++/CLI. There are syntactical differences between the two. MC++ *was* a dog. I understand C++/CLI is pretty decent.

Quote:

Original post by xpnctoc I am about to embark on a clean-up and rewrite of a "game" I wrote 2 years ago. I wrote the original in C++ 6.0, making use of the MFC library. Graphics were done in OpenGL 1.3.

if you do decide to move on to C++ still, you will find that quite a bit has changed since VC++ 6, specifically fixes for almost all of the broken standards, especially with templates.

Quote:

Now, here is my problem. There are a number of things I like about C# -- the easier syntax,

definitely

Quote:

the .NET base,

that's the point of having C++/CLI, to give C++ access to the .NET class library

Quote:

the garbage collector, etc...

that's the point of having C++/CLI, to give C++ access to the .NET garbage collector

Quote:

But as far as a high-speed graphics app goes, having to use wrapper calls for all OpenGL calls makes me worry about performance.

Tao is not just a wrapper around calls to the OpenGL C API, it is new bindings specifically for .NET

Quote:

I also wonder what overhead is incurred by using the Object class instead of void pointers in C++. (Trust me, I would not keep arrays of multiple data types if I had another conceivable alternative.)

First, there is rarely a reason to use the object base type, especially in .NET 2.0 with the new implementation of Generics. .NET Generics do not use the object type, they use the type specified by the template parameter.
Second, it depends on what you define as "overhead". The object type provides a large set of functionallity that is not accessible from a void pointer. To reimplement that functionallity in C++ would probably incur a greater overhead because it would be hacked on top instead of integral to the system.

Quote:

The current version of my game is or a large scale -- about 200 .CPP source code files, plus headers. So obviously it would be easier to import into a MC++ environment than to do a complete rewrite in C#.

that's the point of having C++/CLI, to enable the use of large portions of legacy C++ code in .NET applications

Quote:

I've read that MC++ creates optimized code that C# does not.

there are tradeoffs between the two. C++/CLI has access to the full C++ standard library, which in some cases is optimized better than the .NET class library. However, the C++ std lib isn't as large as the .NET class library.

Quote:

But on the other hand I've read there is a redistibutable app (ngen.exe?) that can do a 1-time JIT compile at install time. Allegedly that EXE creates BETTER optimized code, because it is processor-aware. So which language really produces the better code?

First, all .NET apps are JIT compiled at runtime to pure native code, they are never ran in interpreted mode. Also, that JIT compiled assembly is cached, unless you clear that assembly cache manually or by installing a new version of your application, it will not need to be recompiled again.
Second, NGEN is for combining multiple .NET assemblies into ONE assembly. For example, when using Managed DirectX, I would normally have to include the MDX DLLs seperately from my main application when distributing my program. NGEN allows me to combine them together as one assembly for distribution. That assembly is still a .NET CLI Assembly that will be JIT compiled the first time it is ran.
Third, theoretically speaking, yes, a .NET application has the potential to optimize for the specific machine it is running on, such as enabling SSE3 extentions on processors that support it.

Quote:

Let me conclude by saying that time is not an issue. If C# is ultimately the better way to go, I AM willing to recoding 200 source code files. Time is no issue. End performance is. I don't want to recode 200 files into C# and then, at the end of the process, discover I got better performance from C++. Your input would be greatly appreciated.

In aggregate, a C++/CLI application will perform similarly to a C# application. That's actually the point of .NET, to enable high performance execution from multiple languages. There are rare cases where C++/CLI will generate different MSIL code than C# in a given situation, but for the vast majority of cases they will be equivalent. C++/CLI, C#, VB.NET, JScript.NET, J#.NET, all of them will have mostly the same performance with some minor quirks here and there due to the fact that they are just different compilers.

You've already defined that you want to switch to a .NET language because of the garbage collection. It really doesn't matter which one you take. That said, C# is designed around .NET, C++/CLI and VB.NET are ports *to* .NET. Many of the .NET features just don't *feel* right in any language other than C#. C# 2.0 is a great language, and v3.0 is going to have some really neat stuff (though maybe the new stuff will only be useful in an enterprise setting).

Capn_midnight,

Thanks for your reply. Very insightful, and very helpful. It does give me a few more things to think about, but it also clears up a lot of things that I have been confused about until now. Thanks!

Is .NET still easy to decompile? I remember in the beginning there were loads of decompilers for .NET, this is what kept me from using it for games.

Great point... I know VS.NET 2005 comes with an obfuscator (Dotfuscator - community edition) to mangle variable names and replace easy-to-read case statements with gotos and other ugly code. But I guess the question is: just how effective is this? Seems to me someone with enough patience could still totally disassemble the program. Right now I have no intent to market my game, but if I change my mind down the road, might I regret having it in managed code? (Should I still be using C++ 6.0 for this????)

In fact, as that is really off the point of my original post, I am going to create a separate thread for that...

There is an article somewhere here on Gamedev that talks about Dotfuscator and some other obfuscators. The conclusion was that they were rather good, the decompilers weren't even returning anything that was *correct*.

Yes .NET is easy to decompile, without good obfuscation (which is available) ... and the one thing to remember most is - obfuscators cannot change interfaces exposed to the outside world (obviously) .. which means you will want to seperate your external interface from your internal interface as cleanly as possible (using seperate interface classes, internal scoping, etc.

But truthfully, most of our code is largely the same anyway (hell we get half the ideas from gamedev, and gems BOOKS that everyone has access to) and it only really makes sense to intentionally obfuscate the areas in which you have some business advantage. For most programs maybe 60-90% is the glue that weaves a program out of core parts, while only 10-30% is in any way original or valuable to anyone else - so identify those areas based on your business and competition and give them a simple 1 week scope cleanup cycle about 1/3rd of the way through the project (by this time your core design had better be pretty well finalizd).

Quote:

Original post by xpnctoc Great point... I know VS.NET 2005 comes with an obfuscator (Dotfuscator - community edition) to mangle variable names and replace easy-to-read case statements with gotos and other ugly code. But I guess the question is: just how effective is this? Seems to me someone with enough patience could still totally disassemble the program. Right now I have no intent to market my game, but if I change my mind down the road, might I regret having it in managed code? (Should I still be using C++ 6.0 for this????)

you should upgrade to VC++ 8.0 whether you choose to go managed or not, just because the standard C++ support is so much better.

Quote:

Original post by capn_midnight you should upgrade to VC++ 8.0 whether you choose to go managed or not, just because the standard C++ support is so much better.

I thought that might be the case. I really like the 2005 IDE. At my job all of our programs are in VB.NET and C#, so I haven't brought myself up to speed with the C++ side of things.

Finding those pointer errors will take less time than converting all your existing C++ to C#.

Original post by capn_midnight

Quote:

First, all .NET apps are JIT compiled at runtime to pure native code, they are never ran in interpreted mode. Also, that JIT compiled assembly is cached, unless you clear that assembly cache manually or by installing a new version of your application, it will not need to be recompiled again.

That is actually inaccurate. The JIT-compiled assembly is only cached per run. If you close the app and restart, it gets JITted again. Nothing is put into the GAC uless you specifically sign the assembly and stick it in there.

Quote:

Second, NGEN is for combining multiple .NET assemblies into ONE assembly. For example, when using Managed DirectX, I would normally have to include the MDX DLLs seperately from my main application when distributing my program. NGEN allows me to combine them together as one assembly for distribution. That assembly is still a .NET CLI Assembly that will be JIT compiled the first time it is ran.

I don't know about combining assemblies, but that's not generally what ngen.exe is for. It specifically precompiles an assembly to native format. However, it still needs the original assembly as well for metadata, and if certain things on your system change it'll fall back to that assembly anyway, so it's generally not that useful.

Quote:

Third, theoretically speaking, yes, a .NET application has the potential to optimize for the specific machine it is running on, such as enabling SSE3 extentions on processors that support it.

It should be noted that the JITter might be just as good or better than ngen.exe in this regard as well.