Thread: Why learn C#?

C# is not "better" than C++. C# is very good for creating windows apps with very nice functionality pretty fast. Its kinda a blend of C++, Java, VB(ewwww). So don't think that C# replaces C++ as it is more of a better choice if you want easy windows development.

Originally Posted by Frobozz

One language isn't so much better as another as it is better at a specific task. C++ is excellent for programs that require a lot of speed whereas C# is better for rapidly developing an application.

From a philisophical standpoint, I disagree with your first statement, and your second statement shows a misunderstanding of what C# can do. However, I'll only answer the second one.

Yes, C# can be used for rapid application development. However, that doesn't mean that the speed at run-time is slower than C++ applications. On the contrary, C# applications can often be faster than C++ applications. This is due to the .Net garbage collection vs explicit new/deletes. Run a profiler on a significant C++ app; you'll find an inordinate amount of time being spent allocating and deallocating memory. In any .Net language, the garbage collector not only ensures that you don't have memory leaks, but it also relieves constant thrashing and fragmentation of memory. Further, C# is not limited to rapid application development. From an implementation standpoint, you can do just about anything in C# that you can do in C++.

Originally Posted by Newbeee

Well, I wouldn't consider Garbage Collection to be a difference, because managed C++ (C++/CLI) has it.

Yes, but C++/CLI is a different language than ANSI C++. Like I said, garbage collection is a feature of all .Net languages, including both C# and C++/CLI. However, I (and nearly everyone else that I've heard express an opinion) would greatly advocate C# over C++/CLI. C++/CLI is just enough like ANSI C++ to frustrate you over the differences. Note that you can get garbage collectors for ANSI C++, so it's not an insurmountable advantage.

Originally Posted by Newbeee

So from what I understand, C# is good if you want to create windows applications. But if you want a cross-platform compatibility C++ would be your choice. Would this be correct?

Some people would say "yes". That seems to be because a lot of people equate C# with old school VB. While the .Net languages can be used to create Windows apps, they're also better at cross-platform compatibility than C++. C++ is usually compiled down to a native image. .Net languages are compiled down to MSIL, which can be interpreted and JIT'ed on any platform that has a .Net runtime. The end result is that you have to take your C++ code and re-compile it on other platforms, while the .Net assemblies that are CLS-compliant can simply be reused on multiple platforms without recompilation, similar to Java.

It's too bad people choose not to let go of their pre-concieved notions that relative terms can actually converse clear messages.

C# is a very useful tool in the world of 'business,' -those- types are (like us even) obsessed with effeciency, only from a different perspective.

This language is like a bridge, which connects programmers to the 'business' world. Very good for what it's for, simple, similar to Java, and you can do a lot with it especially in web application.

Should I clarify what I mean by 'bridge'? It's fast, you're boss likes fast, bosses always like things to go fast and smooth. C# in the business world goes fast and smooth. (...more relative terms, how fast IS fast?) At least that's how they market it...

As long as the programmer knows what he/she is doing. It always comes down to the person, just aim for what you want, and study languages associated with that. Don't worry about what's better on the global market scale, only what's better for the job you want to complete.

Pre-disposing yourself to ignorant bias is what causes people to suffer by the end, silly ideals like 'better' can cause real damage.

I hope you understand what I'm saying,


Enjoy!

The problem with .Net's portability is of course the lack of implementations. A JRE exists for just about every platform. CLRs exist for Windows (MS CLR) and a partial one for *nix (Mono). The Windows-centric design of parts of the library also make it difficult to port.

Originally Posted by pianorain

Yes, C# can be used for rapid application development. However, that doesn't mean that the speed at run-time is slower than C++ applications. On the contrary, C# applications can often be faster than C++ applications. This is due to the .Net garbage collection vs explicit new/deletes. Run a profiler on a significant C++ app; you'll find an inordinate amount of time being spent allocating and deallocating memory. In any .Net language, the garbage collector not only ensures that you don't have memory leaks, but it also relieves constant thrashing and fragmentation of memory. Further, C# is not limited to rapid application development. From an implementation standpoint, you can do just about anything in C# that you can do in C++.

CL Code WILL run slower than an optimized native code.
You can do just about anything in C# that you can do with C++. But C# will do many things that you may don't want them to be done.

Originally Posted by siavoshkc

CL Code WILL run slower than an optimized native code.

You're comparing apples and oranges. MSIL code will be slower once per function runtime; after that, it's been JIT'ed into native code. MSIL code has the further advantage of being portable to anything with a .Net runtime; native code doesn't.

If you really care about performance, you'd ngen your MSIL assemblies after building them to eliminate the JIT overhead. Then it's just a matter of which native code is better optimized.

Originally Posted by siavoshkc

But C# will do many things that you may don't want them to be done.

Sounds like a programmer's failure to fully understand and use the language, not a fault of the language design.

Originally Posted by pianorain

You're comparing apples and oranges. MSIL code will be slower once per function runtime; after that, it's been JIT'ed into native code. MSIL code has the further advantage of being portable to anything with a .Net runtime; native code doesn't.

A JIT compiler can never take as much time for optimization as an out-of-execution compiler, thus the produced code will be less efficient.
Also, it requires more memory, because now you have to store the program effectively twice: once the loaded program image with its CIL code, and once the cached JITed native code. Unless you choose to discard the cache (you can't discard the program image until everything has been compiled, because the system's memory granularity is unlikely to be fine enough), but then you have to JIT it again.

If you really care about performance, you'd ngen your MSIL assemblies after building them to eliminate the JIT overhead. Then it's just a matter of which native code is better optimized.

Does ngen retain the CIL code? Then you've just doubled, or even tripled, executable size. Or does it discard it? Goodbye, portability.

It's a tradeoff, no matter how you look at it.

Originally Posted by CornedBee

A JIT compiler can never take as much time for optimization as an out-of-execution compiler, thus the produced code will be less efficient.

I can't really speak to that. It seems that much of the optimization could have been done in compiling from .Net to MSIL, so the JIT compiler may not need to do much optimization.

Originally Posted by CornedBee

Also, it requires more memory, because now you have to store the program effectively twice: once the loaded program image with its CIL code, and once the cached JITed native code. Unless you choose to discard the cache (you can't discard the program image until everything has been compiled, because the system's memory granularity is unlikely to be fine enough), but then you have to JIT it again.

Possibly. I wouldn't be surprised if the runtime loaded the managed methods as objects, then disposed of them after the native code had been generated. Surely that would be a better mode of operation; if I can think of it in five minutes, hopefully one of those Microsoft engineers thought of that in the months they were designing the runtime.

Originally Posted by CornedBee

Does ngen retain the CIL code? Then you've just doubled, or even tripled, executable size. Or does it discard it? Goodbye, portability.

ngen does retain the MSIL, so the file size of the executable is larger. It doesn't seem to be quite doubled, though; just in my experience, it's about 75% larger than the MSIL alone. However, only the native code section of an ngen'ed assembly gets loaded into memory, so it's the same amount of program space at runtime.

Strange. Typically, machine-independent bytecode tends to be smaller than the equivalent native code.

Optimizations during IL compilation are done, but some optimizations depend on the CPU. So you might be able to optimize your IL so that the generated native code is efficient for a specific platform, but that might mean efficiency losses for other platforms.

Originally Posted by How To Become a Hacker

But be aware that you won't reach the skill level of a hacker or even merely a programmer if you only know one or two languages — you need to learn how to think about programming problems in a general way, independent of any one language. To be a real hacker, you need to get to the point where you can learn a new language in days by relating what's in the manual to what you already know. This means you should learn several very different languages.

I think this is a thing a lot of people forget... if you have never read the document: http://catb.org/~esr/faqs/hacker-howto.html Hacker is defined in there, but for now you can just replace hacker with really good programer.

There is no reason to just focus on one language or another, if you have interest in C# and C++ learn both, you will be better off in the end. You can even take the same program for projects and port it to the other language, then you can decide for yourself what is better.

I for one dislike C# and being dependant on a RTE that gives little advantage as far as cross platform goes. I realize Mono is out and being developed, but if Microsoft does what they normally do with APIs (see DirectX) then those people who develope Mono are going to have a hard time keeping up.