Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

kuphryn

C# and C++ Past, Present, Future :: Software Engineer

This topic is 5188 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello. I am a C++ programmer with limited experience (design) using C#. From my experience, C#, like Java, is a derivative of C++. However, Microsoft is able to blend C# and C++, getting the best out of the Java design. With the recent settlement between MS and SUN, I think that MS will remain the top desktop software company. Bottomline: C# should surpass Java given that it is in fact platform-independent. I have some basic questions on the C# language. Currently, does a C# application run on a non-Win32/Win64 platform (UNIX, Mac, wireless)? How does C# compare to C++ in terms of object-oriental design (inheritance, template, etc) on a large-scale project? How does C# compare to C++ for client/server applications including various IPC concepts, multithreading, multiple processes, etc? How does C# compare to C++ for processor-intensive applications including games, 3D-render, multimedia, etc? I read some reviews on two books on C# by Jeff Prosise and Charles Petzold. In general, readers find the books GUI-oriented. How good is C# for performance-imperative applications? Thanks, Kuphryn

Share this post


Link to post
Share on other sites
Advertisement
Currently, does a C# application run on a non-Win32/Win64 platform (UNIX, Mac, wireless)?

Yes. Mono, DotGNU.


How does C# compare to C++ in terms of object-oriental design (inheritance, template, etc) on a large-scale project?

(Templates have nothing to do with object-orientation.) C# is a fully OO language in the vein of Java. All code must exist within the context of a class, even if it is not possible to create instances of that class (eg System.Math).


How does C# compare to C++ for client/server applications including various IPC concepts, multithreading, multiple processes, etc?

With a much more robust and high-level Standard Library (available to all .NET languages), C# far outstrips C++ in this area.


How does C# compare to C++ for processor-intensive applications including games, 3D-render, multimedia, etc?

Current performance losses vary from as little as 3% to as much as 20%, but the theoretical upside for .NET languages is that the runtime can profile and tune them each time they run, resulting in performance increases. In any case, the performance losses are not severe enough to discountenance C# (and .NET) as a viable platform.


I read some reviews on two books on C# by Jeff Prosise and Charles Petzold. In general, readers find the books GUI-oriented. How good is C# for performance-imperative applications?

Excellent. GUI orientation is a reflection of the market, where the majority of applications require usable, familiar and simple interfaces. The Windows Forms (and Gtk# for non-Windows platforms) subsystem makes developing GUI applications a breeze. Nevertheless, .NET is excellent for non-GUI applications. See above for comments on performance.

[Edit: Improved legibility.]

[edited by - Oluseyi on April 5, 2004 6:00:10 PM]

Share this post


Link to post
Share on other sites
C# does run on Win64 and 32 correctly with no redesign to get around software bugs in the implementation. *nix or Mono does not currently implement everything in the specs yet, so no not all will work correctly.

C# does not allow templates.

It does not allow for multiple inheritance on a class. However you can implement Interfaces. Which for the programmer to implement all function in it. Sorta like Pure Virtual functions.

C# is by far easier to implement client and Server apps than C++ with TcpClient/TcpListener to do almost anything you wish.

As for OOP its the top of the line provides better than C++. No ablility of the programmer to create recusive design patterns in class inheritance. Not to mention the implementation of delegates and events...

For performance there is a minimal impact for desktop apps. There has even been a C# Quake2 release with alot of features like Overlay maps to view where things are and people.
Not going to venture to say that it will actually be better to implement a game in it, as of right now no one as even tried to do so from the ground up.

Try a ASP.net book as it will give you a overview of preformance the structure is a good aspect of it but things like design time controls is a good aspect.

Share this post


Link to post
Share on other sites
quote:
Original post by afterburn
For performance there is a minimal impact for desktop apps. There has even been a C# Quake2 release with alot of features like Overlay maps to view where things are and people.
Not going to venture to say that it will actually be better to implement a game in it, as of right now no one as even tried to do so from the ground up.




Actually the Quake2.NET project was the original C source re-written in unmanaged C++, a few changes were made to the unmanaged C++ to make it compile in a managed environment.

The /CLR switch was than used the the application was up and running.


I just wanted to point out that Quake2.NET has nothing to do with C# at all, and furthermore has nothing to do with performance as it was done to show how quickly legacy applications can be converted to C#.

[edited by - Imperil on April 5, 2004 8:20:06 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by afterburn
C# does not allow templates.



The next ''version'' of C# will include generics which serve the same purpose as templates.

Share this post


Link to post
Share on other sites
I''d like to bring in my 2¢ about the runtime performance issue concerning C# (and many other high level languages) and C++. Some people seem to think that high-level languages are very much slower than C++. It is important to keep in mind that languages are not fast, implementations (compilers, interpreters) produce fast or slow code.

With that said, most language implementations (serious implementations, not the kind students do in 6 weeks for school) today produce reasonnably fast code. They also allow to write code much faster than in C++.

Now, the real trick about performance is profiling. Micro-optimizations won''t get you far. The real way to improve a program is to see where its bottlenecks are (there are usually 2 or 3 in non-IO part of programs) and see how those can be optimized. One thing one can do in high-level languages (I know this is true of Python, Ruby, Lisp, etc. not sure about C#) is write functions in C or C++ and then call them from you program. So you can have the benefits of the high-level language (fast development) while retaining the advantages a low-level language offers (fast performance).

Share this post


Link to post
Share on other sites
quote:
Original post by GnuVince
One thing one can do in high-level languages (I know this is true of Python, Ruby, Lisp, etc. not sure about C#) is write functions in C or C++ and then call them from you program. So you can have the benefits of the high-level language (fast development) while retaining the advantages a low-level language offers (fast performance).


You can, or at least you can call code from unmanaged .dlls - I "imported" QueryPerformanceCounter from kernel32.dll and used it in my timer. I don't see why you couldn't do this for other stuff as well EDIT: And you can of course use managed C++ as well..

Regarding speed. Axiom is a C# port of Ogre and they include several ported demos as well. Compare for yourself. According to a test they did, Axiom was in fact a few fps faster than Ogre in some of the tests.

[edited by - frostburn on April 6, 2004 7:52:39 AM]

Share this post


Link to post
Share on other sites
quote:
Some people seem to think that high-level languages are very much slower than C++. It is important to keep in mind that languages are not fast, implementations (compilers, interpreters) produce fast or slow code.

While it sounds nice to say ''languages are not fast; it''s the implementations'' it is fundamentally flawed. If the specification for a language means the implementations cannot be fast then it really is the language.

Luckily for you, C# is strongly typed. This means that the language vs. implementation falls on the implementation (so in this case you''re right). On the other hand, consider Tcl. Can there ever be a ''fast'' Tcl implementation (where everything is specified by the standard to be a string)? Hint: No.

quote:
One thing one can do in high-level languages (I know this is true of Python, Ruby, Lisp, etc. not sure about C#) is write functions in C or C++ and then call them from you program. So you can have the benefits of the high-level language (fast development) while retaining the advantages a low-level language offers (fast performance).
I agree. Unfortunately, a lot of people are scared of adding languages to the toolchain unless they absolutely have to.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!