Archived

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

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

This topic is 4998 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
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
quote:
Original post by flangazor
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.



Well, Tcl is a really badly-designed language, I''ll give you that. I have heard many people call Lisp the "most optimizable language". I know that many Common Lisp and Scheme implementations are really really fast (CMUCL, SBCL, Bigloo) and Lisp is not statically-typed (not to be confused with strongly-typed, which Lisp is) yet can have performance which are often on par with C and C++. Other fast high-level languages include O''Caml and SML.

Share this post


Link to post
Share on other sites
quote:
Original post by haro
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.



And your point is. I already know of that but its not available at the moment. Its only in 2.0 specs. Thats not going to be out of beta for a while longer.

Share this post


Link to post
Share on other sites
quote:
Original post by afterburn
And your point is. I already know of that but its not available at the moment. Its only in 2.0 specs. Thats not going to be out of beta for a while longer.
q4 is only a few months away ... close enough to start learning about it. The alpha stuff is readily available from the various MSDN events that microsoft holds in most towns for free. or if you know someone that has an MSDN subscription, they can order you a cd with Whidbey on it for a few bucks.

The point is, it can be had if you''re really interested. Lookup your local microsoft regional director and I''m sure they''ll be able to help you out.

Joel Martinez
http://www.codecube.net/

Share this post


Link to post
Share on other sites
quote:
Original post by haro
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.


Generics arent quite templates. They offer some basic functionality similar to templates - that is, you can create generic containers using generic. However, according to the specs, there are several differences.

Templates are only compiled if an instantiation of a template class exists in the code. This generates (at comile-time), a class with the template argument as a param. If you have a template class std::list, and you instantiate like so:
list mylist;
the compiler will generate a new class of type list< mytype >. This is a completely different class from list< othertype >.

In .NET, generics will simply replace the generic type with the runtime type in the CLR. This does not offer the compile-time 'class generation' that templates do.

Because C++ generates classes at compile time, there are several features of templates that have been exploited by geeky programmers across the world... most notably Andrei A. in Modern C++ Design. Techniques like partial template specialization and metaprogramming (functions that evaluate upon template expansion at compile-time) will not appear in C# anytime soon.

One of the reasons for this is that C# is an object oriented language, C++ is not. C++ offers OO facilities, but is not OO in the sense that Smalltalk, Java and C# are. Templates dont fit in too well with the overall OO paradigm, and therefore their use is restricted in the OO world of C#.

[edited by - psamty10 on April 6, 2004 12:23:48 PM]

Share this post


Link to post
Share on other sites
I often read about fully OO feature in languages including Java and C#.

How important is object-oriented paradigm?

Nonetheless, the good things seem to point to platform-independence rather than the OO paradigm.

How would you evaluate fully OO paradigm (C#, Java, etc) to a flexible programming language like C++ that gives the developer unsurpassed control without going to ASM?

Kuphryn

Share this post


Link to post
Share on other sites
quote:
Original post by psamty10
Because C++ generates classes at compile time, there are several features of templates that have been exploited by geeky programmers across the world... most notably Andrei A. in Modern C++ Design. Techniques like partial template specialization and metaprogramming (functions that evaluate upon template expansion at compile-time) will not appear in C# anytime soon.

You may find this article interesting.

quote:
Again, it turns out that this ability was old before templates were a glimmer in Bjarne Stroustrup''s eye in the form of Lisp macros. You may recoil at the use of that name, but don''t worry: Lisp macros are much more pleasant to work with than their higher-profile cousins. At about the same time Kernigan and Ritchie were inventing C and C preprocessor macros, a group at the MIT Media Lab was inventing a system called MacLISP that introduced Lisp macros, a totally different implementation of the macro concept that survives to this day in Common Lisp and Scheme as well as in a number of offshoots and related languages.

Further, C# is implementing an ML style generics system. Consider this from the article:
quote:
For one thing, templates hurt the C++ compiler''s ability to generate efficient code. It might surprise you to hear that, considering that C++ is "efficient" while functional languages like ML and Scheme are "inefficient," but it''s true. C++ templates hide your intentions from the compiler: did you mean type abstraction? Did you mean a syntax extension? Did you mean constant-folding or compile-time code generation? The compiler doesn''t know, so it has to just blindly apply the copy-and-paste strategy and then see what happens. In ML or Scheme, though, aside from the individual benefits described above, the simple fact that you''re telling the compiler what you want to achieve lets it optimize for you much more effectively.

Share this post


Link to post
Share on other sites
quote:
One of the reasons for this is that C# is an object oriented language, C++ is not. C++ offers OO facilities, but is not OO in the sense that Smalltalk, Java and C# are. Templates dont fit in too well with the overall OO paradigm, and therefore their use is restricted in the OO world of C#.


Not every problem is best solved using OO, however, so I don''t see this so-called "OO Purity" as a virtue or advantage over C++ at all.

Share this post


Link to post
Share on other sites
quote:
Original post by dmikesell
quote:
One of the reasons for this is that C# is an object oriented language, C++ is not. C++ offers OO facilities, but is not OO in the sense that Smalltalk, Java and C# are. Templates dont fit in too well with the overall OO paradigm, and therefore their use is restricted in the OO world of C#.


Not every problem is best solved using OO, however, so I don''t see this so-called "OO Purity" as a virtue or advantage over C++ at all.


Well, if you are truly, purely, 100% OO (Smalltalk, no other languages is), it can open up some very interesting possibilities, especially with dynamic typing. I don''t know if you ever used a Smalltalk programming environment, but it''s far more advanced than anything available for C++, C#, Java, etc. The environment knows you are going to go OO, so it can assume a large number of things and it gives you great support for that paradigm.

Share this post


Link to post
Share on other sites
quote:
Original post by dmikesell
quote:
One of the reasons for this is that C# is an object oriented language, C++ is not. C++ offers OO facilities, but is not OO in the sense that Smalltalk, Java and C# are. Templates dont fit in too well with the overall OO paradigm, and therefore their use is restricted in the OO world of C#.


Not every problem is best solved using OO, however, so I don''t see this so-called "OO Purity" as a virtue or advantage over C++ at all.


Neither do I. There are advantages to both sides. Productivity definitely goes up with the ''pure'' OO languages, but at the price of control.

quote:

Well, if you are truly, purely, 100% OO (Smalltalk, no other languages is), it can open up some very interesting possibilities, especially with dynamic typing. I don''t know if you ever used a Smalltalk programming environment, but it''s far more advanced than anything available for C++, C#, Java, etc. The environment knows you are going to go OO, so it can assume a large number of things and it gives you great support for that paradigm.



Fair enough. Ive never used Smalltalk myself, but it obviously is a language that almost all modern languages seem to emulate. To me, Java and C# are pure OO languages too, in that everything is a derivative of an ''object'' class - and they too give you full support for the OO paradigm.

If there''s something Smalltalk has that these languages dont, I dont know about it - perhaps you could indulge me with an explanation, it sounds real interesting.

Share this post


Link to post
Share on other sites
quote:
Original post by dmikesell
Not every problem is best solved using OO, however, so I don''t see this so-called "OO Purity" as a virtue or advantage over C++ at all.

I concur. I''ve seen far too many Java projects revel in "OO purity" by creating tons of factories that are little more than switch statements when the switch statement would have been fine by itself.

quote:
Neither do I. There are advantages to both sides. Productivity definitely goes up with the ''pure'' OO languages, but at the price of control.

Is this because of pure OO, or because of good class libraries? Or because pure OO languages are higher level?

I don''t think Java and C# are pure OO. In Smalltalk, everything is an object. Objects communicate by message passing. Messages are objects too. You can call object methods without having to know the type of the object. If the method isn''t implemented, I think you get a doesNotUnderstand message. It is really loose. On the downside, some errors that would be caught at compile time are now runtime errors. Java and C# only call themselves pure OO because thats the only choice they give you. Personally I wish C# would aggresively incorporate even more functional language features into it.

Share this post


Link to post
Share on other sites
Well, let me put it in a better way. Most OO languages (Java, C#) offer memory management and a decent set of class libraries. That is a possible reason for a productivity increase, not the OO nature of the language. So I retract my earlier statement of OO langs being more productive. Lets just say managed languages are typically more productive.

[edited by - psamty10 on April 6, 2004 3:13:59 PM]

Share this post


Link to post
Share on other sites
On C#:
It is a higher level language than C#. Just from spending five minutes with the language you can tell it is an evolution of both Java and C++. It doesn''t bill itself as a language for average programmers (like Java does) and it has its own learning curve in areas. However it isn''t what C++ is so you should be fine. The .NET runtime is awesome and you will feel like a super-programmer when using it. I think it is a very expressive language, with language support for garbage collection, real object properties (that make getters/setters now look ridiculous in retrospect; Delphi had these as well), signals and slots (called events) and wide character strings.

On the downside, it is sad that generics will not come close to the C++ templates. I''m guess there will be less need for them in C#, but at the same time I can only imagine what sort of nifty things could be made in C# with more powerful generics. I was really hoping to see something like Loki#.

Don''t listen to the GameDev kids (most of whom haven''t finished a game) who cry that these higher level languages are dumbing down programming because only real programmers do X (where X is anything from memory management to goto to writing assembly). Nor should you be concerned about performance. Try it out for yourself. MS likes this language enough to bet their next OS on it, and even the die-hard Linux-heads (once we figure out exactly what the TCPA entails) are willing to admit they are eager to see what Longhorn will be like.

Share this post


Link to post
Share on other sites
quote:
Original post by psamty10
[...]Productivity definitely goes up with the 'pure' OO languages, but at the price of control.[...]
Are you sure it is because of the OO or the language though? You musn't fallaciously extend a correlation into a cause<->effect.

I'd bet that a large part of the productivity increase is from the libraries included with newer languages. Many 'older' languages, like C, C++, and Common Lisp do not include things like multithreading, a GUI Library, and sockets in their standards and those things seem to now be practically required for an average application. Since they aren't standardized, everybody has their own library and code is much more difficult to share because it depends on certain libraries being used.

Of course, inside a single corporation or so you could just declare your own standards and have all coders working with the same set, but it'd take more work to get started because you'd need to assembly the libraries yourself.

I'd bet that if an older language were upgraded with standard libraries for such things, you'd see the same productivity increase if not more.

Edit: Oh well, a few minutes late with finishing this post =-/

[edited by - Extrarius on April 6, 2004 3:23:58 PM]

Share this post


Link to post
Share on other sites
Hey, what''s going on here? 23 posts comparing C++, C#, Java, and Smalltalk and I haven''t seen the word "sucks" once. Did I slip into a parallel universe somehow?

Share this post


Link to post
Share on other sites