C++ was my first language. I'm glad I did this language too because it taught my mind not to think in abstract ways as other languages do. Knowing me, I'd be more dependent on them later if it weren't for C++, because my mind would tell me C++ is too hard, so why bother? I can achieve better with Dark Basic! I suppose it is different for everyone.

Quote:Original post by Kahsm
We all know about the hit to C# performance over C++. It is obvious it will never be as fast due to it's nature. The question is at what point does that hit become trivial compared to the overall speed of the systems. personally, I think we are past that.

Actually you are quite wrong in this blanket statement. Considering once the JIT optimizations in future versions start taking effect you will be able to write a single math library and the JITer will optimize for that exact system, SSE, SSE2, MMX, etc. I'm not sure if people realize how much time it takes to build up these math libraries. Sure large studios already have these, but from indie level all the way up to medium sized studios C#'s free optimizations will save months of development time and where adhering to a schedule the C# version will run faster because of free optimizations whereas there was no time to write the C++ optimizations.

Quote:
Every once in awhile you get into situations where the GC gives you a little slow down, it's true.

Than you must be doing something extremely wrong. The only time I have seen these 'GC slow downs' are from bad code or people not using the correct patterns.

Quote:
However, there _IS_ an unsafe mode for C#. You can write unmanaged code with it if you must.

Unsafe mode is not unmanaged code at all, it is just not CLR-safe. I actually think it's better to wrap something in CLI/C++ and use that class library in your C# application than using this block, but to each his own.

Quote:
And we NEVER have to play with memory. No new-ing an array then memcpy-ing over values, no deleting, no keeping track of everything. Memory is almost as bad as keeping track of shared items in a multithreaded environment.

Another untrue statement. Sure you may not be keeping track of your memory allocations with new/delete, but you can still easily leave memory leaks, create bubbles in the GC, leave resources active (not using dispose pattern), etc.

Quote:
I think we can spare a little for a GC and pump out still gorgeous games much faster.

I don't see why you keep mentioning the GC because anybody programming in C# using the correct patterns and watching what they are doing with memory is not going to run into issues with the GC. Although if you do what you mentioned above, and just not worry about how you allocate your memory and resources, I can plainly see why this is an issue for you.

Sorry I don't mean any offence to you with these posts, I just wanted to clear up some of the common misconceptions that people spread around.

Quote:Original post by QuadMV
c# is only going to run on Windows (and maybe the xbox) right? If anyone wants to write something portable to run on unix/linux, ps2 or gcube, c# wont be portable will it?

There are implementations of the CLR for NIX systems but not on consoles. Although you use a tool for it's intended purpose so imo C# is the tool for Windows PC development but I wouldn't try to jam it onto a console.

Quote:
Especially if you want to build an app that does a lot of database or string manipulation. I’ve found with java that it’s very inefficient at string manipulation.

This thread is about C# so why are you trying to bring Java string manipulation in here? Should I start comparing VB and C++ math libraries?

Quote:
If you are writing server side code, it might run fine with one or two clients connecting and testing it, but put 100 or a thousand clients on it, and you might quickly find that the inefficient memory management kills you.

Than you must not know what you are doing properly because there are many enterprise applications written in C#. You could also look at games and note that RunUO the emulator for Ultima Online written in C# has now been load tested with over 7500 concurrent players on a single machine! That pretty much debunks your 100-1000 clients statement as RunUO has been able to do up to 3000 clients with ease and it has just been getting better recently, this is also just using the TCP protocol.

Quote:
If you want to have control over when a memory buffer is REUSED (in java it often flags an existing area for garbage collections and allocated a new area) and RELEASED (meaning give me back the resources NOW, not when it decided to) then java isn’t a good selection, and I assume neither is c#.

Than you assume wrong, again you are trying to compare C# and Java with the usual blanket garbage statements.

Quote:
If you are writing a single user app, you might never see it, but I’ve seen it a lot in the business world when we get thousands of uses trying to hit a server side app.

I would say 7500 concurrent connections to a game server while keeping it completely playable is quite the achievement. This actually outperforms EAs servers written in C++ by over THREE TIMES as many concurrent connections.

Quote:
I've heard a lot of people comment that c# is easier to read and easier to debug and creates cleaner code. Quite frankly that's a bunch of _rap.

If you don't think C# is much cleaner code than no wonder you can make all these blanket statements, you really have no idea what you are talking about.

Quote:
Thanks, and what ever language you choose, just remember to have fun, and enjoy yourself. The best high for a programmer is getting the nasty bug fixed or that really cool new feature to work, so have fun and keep it light.

Finally I can agree with one of your statements :)


Also after all of those garbage blanket statements I would like to invite you to benchmark against me. You can write your 'hyper-optimized' C++/ASM code and I will write in C#, we'll write a quick game engine. I'll gaurantee you write now that the C# engine will outperform yours unless we are talking about spending a year or more on the project.