Why learn C#?

This is a discussion on Why learn C#? within the C# Programming forums, part of the General Programming Boards category; Can anybody please explain why is C# better than C++. What can C# offer that C++ can't. Is C# the ...

  1. #1
    Registered User
    Join Date
    Jun 2006
    Posts
    30

    Why learn C#?

    Can anybody please explain why is C# better than C++. What can C# offer that C++ can't. Is C# the future of windows programming? I've tried to search the web, but all I got was syntax differences and comparison of language's features. I'm just trying to think ahead and decide if I really need to pay attention to C#. Any info would be appreciated.

  2. #2
    Sweet
    Join Date
    Aug 2002
    Location
    Tucson, Arizona
    Posts
    1,812
    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.
    Woop?

  3. #3
    Registered User Frobozz's Avatar
    Join Date
    Dec 2002
    Posts
    546
    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.

  4. #4
    Anti-Poster
    Join Date
    Feb 2002
    Posts
    1,399
    Quote 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++.
    If I did your homework for you, then you might pass your class without learning how to write a program like this. Then you might graduate and get your degree without learning how to write a program like this. You might become a professional programmer without knowing how to write a program like this. Someday you might work on a project with me without knowing how to write a program like this. Then I would have to do you serious bodily harm. - Jack Klein

  5. #5
    Registered User
    Join Date
    Jun 2006
    Posts
    30
    Well, I wouldn't consider Garbage Collection to be a difference, because managed C++ (C++/CLI) has it. 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?

  6. #6
    Anti-Poster
    Join Date
    Feb 2002
    Posts
    1,399
    Quote 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.
    Quote 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.
    If I did your homework for you, then you might pass your class without learning how to write a program like this. Then you might graduate and get your degree without learning how to write a program like this. You might become a professional programmer without knowing how to write a program like this. Someday you might work on a project with me without knowing how to write a program like this. Then I would have to do you serious bodily harm. - Jack Klein

  7. #7
    Registered User
    Join Date
    Jul 2006
    Posts
    162
    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!
    Last edited by simpleid; 07-01-2006 at 05:14 AM.

  8. #8
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  9. #9
    and the Hat of Clumsiness GanglyLamb's Avatar
    Join Date
    Oct 2002
    Location
    between photons and phonons
    Posts
    1,109
    True but the point pianorain gave still stands, write C# ( or any other .Net or code that results in JIT interpretation ) and there will not be any need to recompile while changing platform.

    Its just too bad projects like Mono are rare... I just cant wait untill sockets are implemented correctly in Mono ( actually I cant wait untill everything is implemented ).

    That way I'll be able to completely run under Linux instead of having to change to windows to develop my C# applications.

  10. #10
    System Novice siavoshkc's Avatar
    Join Date
    Jan 2006
    Location
    Tehran
    Posts
    1,236
    Quote 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.
    Last edited by siavoshkc; 07-19-2006 at 06:11 AM.
    Learn C++ (C++ Books, C Books, FAQ, Forum Search)
    Code painter latest version on sourceforge DOWNLOAD NOW!
    Download FSB Data Integrity Tester.
    Siavosh K C

  11. #11
    Anti-Poster
    Join Date
    Feb 2002
    Posts
    1,399
    Quote 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.

    Quote 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.
    Last edited by pianorain; 07-19-2006 at 08:51 AM.
    If I did your homework for you, then you might pass your class without learning how to write a program like this. Then you might graduate and get your degree without learning how to write a program like this. You might become a professional programmer without knowing how to write a program like this. Someday you might work on a project with me without knowing how to write a program like this. Then I would have to do you serious bodily harm. - Jack Klein

  12. #12
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote 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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  13. #13
    Anti-Poster
    Join Date
    Feb 2002
    Posts
    1,399
    Quote 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.
    Quote 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.
    Quote 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.
    If I did your homework for you, then you might pass your class without learning how to write a program like this. Then you might graduate and get your degree without learning how to write a program like this. You might become a professional programmer without knowing how to write a program like this. Someday you might work on a project with me without knowing how to write a program like this. Then I would have to do you serious bodily harm. - Jack Klein

  14. #14
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  15. #15
    pwns nooblars
    Join Date
    Oct 2005
    Location
    Portland, Or
    Posts
    1,094
    Quote 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.

Page 1 of 3 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Do you ever try to learn too much?
    By Stonehambey in forum A Brief History of Cprogramming.com
    Replies: 11
    Last Post: 06-17-2008, 08:55 AM
  2. Looking to learn C++
    By Fuzzy91 in forum C++ Programming
    Replies: 40
    Last Post: 04-13-2006, 03:38 AM
  3. You have to learn C in order to learn C++
    By gandalf_bar in forum A Brief History of Cprogramming.com
    Replies: 20
    Last Post: 07-16-2004, 11:33 AM
  4. Novice trying to learn C++
    By dead in forum C++ Programming
    Replies: 10
    Last Post: 12-01-2003, 09:25 PM
  5. Advice on how to being to learn C++
    By VenomUK in forum C++ Programming
    Replies: 9
    Last Post: 05-18-2002, 02:06 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21