Re: [GD-General] C# versus C++ for game engines
Brought to you by:
vexxed72
From: Colin F. <cp...@ea...> - 2003-02-20 18:40:45
|
2003 February 20th Thursday [NOTE: I'm sorry about the irrelevant comments regarding certain Microsoft products.] One thing I really like about C# is the crash tracing for release builds. Creating a similar feature in C++ is VERY platform dependent, and I think you need to generate a *.PDB file with all of your symbols, along with the DbgHlp.dll. It's a fact that sometimes a crash bug only appears in the release version of the application. Sometimes the crash occurs on a test machine that doesn't have Visual Studio, and sometimes it is difficult to do remote debugging. Yes, applications should handle all exceptions, but even so, you can log the exception in plain text form for study, or users in the field can transmit the stack trace to you. This stack trace may still be relevant even if you are still making changes to the code. Reflection is also very cool. With an in-game editor you can get information about game objects, or manipulate objects. Doing something like this in C++ requires a lot of discipline and extra code, or *.PDB or *.MAP files in conjunction with a symbol parsing mechanism like the one used by the FuBi library. I regard garbage collection as a nice safety net just in case someone forgets to free a memory allocation. In C++ you would have to write your own memory manager, or create memory buffer objects that get destroyed when out of scope, or use smart pointers, etc, to get some assurance that an allocation won't slip through the cracks. Maybe it doesn't rank high on the list of good reasons to switch to C#, but it is nice that there is no such thing as a "header" file (*.H) in C#. It's a bit of a pain to keep the *.CPP and *.H files synchronized; it's just a chore. C# offers a huge set of very convenient API's. You can add FTP, ZIP, HTTP, XML, etc, to your game quite easily. The contanier classes and string class have many interesting methods. Gone are the days of having to typedef your own primitive data types (INT16, UINT32, FLOAT32, etc) to prevent platform dependencies! The strictness of the C# compiler means that there will be fewer silly errors that wasted ENORMOUS amounts of time on C/C++ projects. I think that this aspect alone makes switching to C# worthwhile for new PC projects. I was on a 9-month project for a major publisher, and during the last three months, when the entire team was living at the office, I think I spent half the time fixing SILLY bugs caused by uninitialized variables, etc. All such errors would have been impossible with C#, since the compiler is strict about initializing variables, type safety, use of boolean in conditional expressions, no more "fall through" in switch cases, and the option of explicitly designating parameters as input or output. My post was written to solicit responses from people who had written game engine code in C# to learn about their experiences. For some people, the transition to C# doesn't make sense; I won't argue that. I'm interested in hearing about actual C# game engine experiences. --- Colin cp...@ea... P.S.: For the record, I am a happy Windows programmer, and I use many Microsoft products (Visual Studio .NET, MS-Office), and I really like Windows 2000. I bought all Microsoft software from stores at retail prices, going back to Visual Studio 4.0 and Windows 95 on my first PC. I have fifty books on various aspects of Windows programming and software. I really like Win32, DirectSound, WinSock, VfW / DirectShow, MFC, etc. It so happens that I have also done a lot of Linux programming, too, including kernel mode software, video capture drivers, etc. I am a big fan of Linux, and I hope the Mono project is a big success so that my C# code will work under Linux, too. Everyone has their gripes about software products, and I'm sorry that I shared a couple of my gripes about certain Microsoft products. But "Microsoft-bashing"? I don't think any intelligent person could accept broad generalizations about a corporation or its products, but at the same time I'm not ashamed to share my feelings about specific aspects of products that I think are mistakes, even if features can theoretically be "turned off" (burden on consumer), etc. Anyhow, I know all of this is not appropriate for this forum. I just want to point out that my previous remarks weren't meant to fuel any silly generalized dislike (or like) of Microsoft. |