Re: [GD-General] C# versus C++ for game engines

[Colin F. <cp...@ea...>]

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.