C++ vs C#
-
I thought of replying to this under the XP/.NET thread but then thought that my reply was tangential to that topic. Nish [BusterBoy] wrote: And maybe some C++ programmers who had a lot of trouble with their coding might consider downgrading themselves to C# :-D What are the big differences between C++ and C#? Things that come to mind are Memory management/Pointers Is this such a big deal as it is oft made out to be? More often than not we use class wrappers that manage memory. Having control over the memory matters sometimes (device drivers come to mind) but does not in most instances. Deterministic finalization (closure whatever) is more important. With C# this requires about the same discipline as with C++. Only the usage paradigm is a little different. Direct access to memory is also a bad thing when you are doing distributed programming. For one it becomes harder to remote interfaces that have void pointers etc. It requires greater discipline on the part of programmers to create interfaces that can be properly remoted. In a managed scenario this is taken care of by the runtime. Speed/Performance This is also not such a big issue. The Jit'd code is fast. It is the same assembly code. I agree that it may not be the exact same tight code that is produced by the C++ compiler. But in most applications you will not see any difference. Many cite the start up time to say that .NET applications are slower. That is incorrect. Start up time can be greatly reduced by pre-jit'ing the code (thought according to MS this may lead to a larger working set than required). Also, this is usually a one time hit. Subsequent invocations are fast. Jit'ing also has the advantage that the code produced could be optimised for different systems. For example, code produced for multi-processor machines could be different than that produced for uni-processor machines. Native access to the WIN32 API WIN32 interop is not so bad with .NET. It is not as natural as calling C functions from C++ but it is not so bad either. Once you are used to it it only takes a few seconds to figure out the call (there could also be a tool written that will do this). Then again you do not have to make that many API calls for most applications. Multiple inheritance MI is useful in some cases. But there are ways that you can get around not having MI. I do think that this is a disadvantage though not a crippling one. More free libraries for specialized tasks are available for C
G. Suresh wrote: Speed/Performance This is also not such a big issue. The Jit'd code is fast. It is the same assembly code. I agree that it may not be the exact same tight code that is produced by the C++ compiler. But in most applications you will not see any difference. Many cite the start up time to say that .NET applications are slower. That is incorrect. Start up time can be greatly reduced by pre-jit'ing the code (thought according to MS this may lead to a larger working set than required). Also, this is usually a one time hit. Subsequent invocations are fast. Jit'ing also has the advantage that the code produced could be optimised for different systems. For example, code produced for multi-processor machines could be different than that produced for uni-processor machines. In theory, yes. But try for yourself. Do some real measurments, and you will be surprised (I was not). Also, compare C# with Java, and you're gonna start to laugh. I vote pro drink :beer:
-
G. Suresh wrote: Speed/Performance This is also not such a big issue. The Jit'd code is fast. It is the same assembly code. I agree that it may not be the exact same tight code that is produced by the C++ compiler. But in most applications you will not see any difference. Many cite the start up time to say that .NET applications are slower. That is incorrect. Start up time can be greatly reduced by pre-jit'ing the code (thought according to MS this may lead to a larger working set than required). Also, this is usually a one time hit. Subsequent invocations are fast. Jit'ing also has the advantage that the code produced could be optimised for different systems. For example, code produced for multi-processor machines could be different than that produced for uni-processor machines. In theory, yes. But try for yourself. Do some real measurments, and you will be surprised (I was not). Also, compare C# with Java, and you're gonna start to laugh. I vote pro drink :beer:
You can't really make reasonable comparisons till the final release is out. cheers, Chris Maunder
-
G. Suresh wrote: Speed/Performance This is also not such a big issue. The Jit'd code is fast. It is the same assembly code. I agree that it may not be the exact same tight code that is produced by the C++ compiler. But in most applications you will not see any difference. Many cite the start up time to say that .NET applications are slower. That is incorrect. Start up time can be greatly reduced by pre-jit'ing the code (thought according to MS this may lead to a larger working set than required). Also, this is usually a one time hit. Subsequent invocations are fast. Jit'ing also has the advantage that the code produced could be optimised for different systems. For example, code produced for multi-processor machines could be different than that produced for uni-processor machines. In theory, yes. But try for yourself. Do some real measurments, and you will be surprised (I was not). Also, compare C# with Java, and you're gonna start to laugh. I vote pro drink :beer:
-
I thought of replying to this under the XP/.NET thread but then thought that my reply was tangential to that topic. Nish [BusterBoy] wrote: And maybe some C++ programmers who had a lot of trouble with their coding might consider downgrading themselves to C# :-D What are the big differences between C++ and C#? Things that come to mind are Memory management/Pointers Is this such a big deal as it is oft made out to be? More often than not we use class wrappers that manage memory. Having control over the memory matters sometimes (device drivers come to mind) but does not in most instances. Deterministic finalization (closure whatever) is more important. With C# this requires about the same discipline as with C++. Only the usage paradigm is a little different. Direct access to memory is also a bad thing when you are doing distributed programming. For one it becomes harder to remote interfaces that have void pointers etc. It requires greater discipline on the part of programmers to create interfaces that can be properly remoted. In a managed scenario this is taken care of by the runtime. Speed/Performance This is also not such a big issue. The Jit'd code is fast. It is the same assembly code. I agree that it may not be the exact same tight code that is produced by the C++ compiler. But in most applications you will not see any difference. Many cite the start up time to say that .NET applications are slower. That is incorrect. Start up time can be greatly reduced by pre-jit'ing the code (thought according to MS this may lead to a larger working set than required). Also, this is usually a one time hit. Subsequent invocations are fast. Jit'ing also has the advantage that the code produced could be optimised for different systems. For example, code produced for multi-processor machines could be different than that produced for uni-processor machines. Native access to the WIN32 API WIN32 interop is not so bad with .NET. It is not as natural as calling C functions from C++ but it is not so bad either. Once you are used to it it only takes a few seconds to figure out the call (there could also be a tool written that will do this). Then again you do not have to make that many API calls for most applications. Multiple inheritance MI is useful in some cases. But there are ways that you can get around not having MI. I do think that this is a disadvantage though not a crippling one. More free libraries for specialized tasks are available for C
The old battle of languages still rages on.. G. Suresh wrote: But in most applications you will not see any difference For smaller apps, you may be right, but when it comes to large scale mission critical apps, think twice. G. Suresh wrote: Also, this is usually a one time hit. Subsequent invocations are fast. But when my customers see my apps starting up slow for the first time, they won't probably know what will happen second time. G. Suresh wrote: WIN32 interop is not so bad with .NET. But would you want to write the extra interop specific code every time you invoke a Win32 API? G. Suresh wrote: There are definitely more free (and commercial libraries) available for C++ than for C#. But I think that we will see lots of these libraries ported to C# in the next several months. Talking about reinventing the wheel. G. Suresh wrote: I like the productivity that .NET and C# bring to the table. The API is much more intuitive. Learning curve wise to get the same quality of applications C# would have a lesser learning curve. I too like the design architecture of .NET framework, especially its simplicity and ease of use. But that is not to say that it wasn't possible to make a .NET like class library using a native C++ framework. You never know if that happens sometime in future. The bottom line of these arguments is: use the language that fits your need. There is nothing wrong to learn and use new languages and frameworks as long as you can keep your customers happy. This has always been since when VB first came out, and now with C#. // Fazlul
Get RadVC today! Play RAD in VC++ http://www.capitolsoft.com
-
How do they compare?? 'Love is an obsessive delusion that is cured by marriage.' Dr. Karl Bowman
I'm sorry, but I am not allowed to publish any benchmarks. Just go and try. A tip: try a program with lots of memory allocations. I vote pro drink :beer:
-
You can't really make reasonable comparisons till the final release is out. cheers, Chris Maunder
Chris Maunder wrote: You can't really make reasonable comparisons till the final release is out Of course, you are right. Also, I might add that for the server-side applications speed is not crucial, because you can always add more hardware. I work on a server-side application in C++ (with ISAPI) and sometimes I wish I used Java or C#. :-O I vote pro drink :beer:
-
I'm sorry, but I am not allowed to publish any benchmarks. Just go and try. A tip: try a program with lots of memory allocations. I vote pro drink :beer:
-
I'm sorry, but I am not allowed to publish any benchmarks. Just go and try. A tip: try a program with lots of memory allocations. I vote pro drink :beer:
Isn't that something you're supposed to avoid if you want good performance? That's why game programmers publish tips such as allocating one enormous block of memory at startup then using it sort of like a stack. You can't do that in exactly the same way with C#, but then there are other ways to make things perform better -- and allocating, reallocating, and allocating some more isn't one of those ways. John
-
The old battle of languages still rages on.. G. Suresh wrote: But in most applications you will not see any difference For smaller apps, you may be right, but when it comes to large scale mission critical apps, think twice. G. Suresh wrote: Also, this is usually a one time hit. Subsequent invocations are fast. But when my customers see my apps starting up slow for the first time, they won't probably know what will happen second time. G. Suresh wrote: WIN32 interop is not so bad with .NET. But would you want to write the extra interop specific code every time you invoke a Win32 API? G. Suresh wrote: There are definitely more free (and commercial libraries) available for C++ than for C#. But I think that we will see lots of these libraries ported to C# in the next several months. Talking about reinventing the wheel. G. Suresh wrote: I like the productivity that .NET and C# bring to the table. The API is much more intuitive. Learning curve wise to get the same quality of applications C# would have a lesser learning curve. I too like the design architecture of .NET framework, especially its simplicity and ease of use. But that is not to say that it wasn't possible to make a .NET like class library using a native C++ framework. You never know if that happens sometime in future. The bottom line of these arguments is: use the language that fits your need. There is nothing wrong to learn and use new languages and frameworks as long as you can keep your customers happy. This has always been since when VB first came out, and now with C#. // Fazlul
Get RadVC today! Play RAD in VC++ http://www.capitolsoft.com
G. Suresh wrote: There are definitely more free (and commercial libraries) available for C++ than for C#. But I think that we will see lots of these libraries ported to C# in the next several months. Talking about reinventing the wheel. Maybe, but the newly reinvented "wheels" can work in every .NET language without any changes. Previously, each new component needed to be reinvented for each language. (COM helped prevent that, but .NET works with COM too.) John
-
G. Suresh wrote: There are definitely more free (and commercial libraries) available for C++ than for C#. But I think that we will see lots of these libraries ported to C# in the next several months. Talking about reinventing the wheel. Maybe, but the newly reinvented "wheels" can work in every .NET language without any changes. Previously, each new component needed to be reinvented for each language. (COM helped prevent that, but .NET works with COM too.) John
The old wheels can be used in .NET using interop services too. That is another thing I like about .NET // Fazlul
Get RadVC today! Play RAD in VC++ http://www.capitolsoft.com
-
The old battle of languages still rages on.. G. Suresh wrote: But in most applications you will not see any difference For smaller apps, you may be right, but when it comes to large scale mission critical apps, think twice. G. Suresh wrote: Also, this is usually a one time hit. Subsequent invocations are fast. But when my customers see my apps starting up slow for the first time, they won't probably know what will happen second time. G. Suresh wrote: WIN32 interop is not so bad with .NET. But would you want to write the extra interop specific code every time you invoke a Win32 API? G. Suresh wrote: There are definitely more free (and commercial libraries) available for C++ than for C#. But I think that we will see lots of these libraries ported to C# in the next several months. Talking about reinventing the wheel. G. Suresh wrote: I like the productivity that .NET and C# bring to the table. The API is much more intuitive. Learning curve wise to get the same quality of applications C# would have a lesser learning curve. I too like the design architecture of .NET framework, especially its simplicity and ease of use. But that is not to say that it wasn't possible to make a .NET like class library using a native C++ framework. You never know if that happens sometime in future. The bottom line of these arguments is: use the language that fits your need. There is nothing wrong to learn and use new languages and frameworks as long as you can keep your customers happy. This has always been since when VB first came out, and now with C#. // Fazlul
Get RadVC today! Play RAD in VC++ http://www.capitolsoft.com
Fazlul Kabir wrote: G. Suresh wrote: But in most applications you will not see any difference For smaller apps, you may be right, but when it comes to large scale mission critical apps, think twice. Why? I would think writing the app in a more "safe" way would override any pressing concerns for speed. Fazlul Kabir wrote: G. Suresh wrote: Also, this is usually a one time hit. Subsequent invocations are fast. But when my customers see my apps starting up slow for the first time, they won't probably know what will happen second time. The default is to JIT any code on a per-method basis, not the entire app at once. This should be fast enough out of the starting blocks. Fazlul Kabir wrote: G. Suresh wrote: WIN32 interop is not so bad with .NET. But would you want to write the extra interop specific code every time you invoke a Win32 API? First, you'd only need to write the interop code once. Two, most of the win32 api is already in the managed library. Fazlul Kabir wrote: G. Suresh wrote: There are definitely more free (and commercial libraries) available for C++ than for C#. But I think that we will see lots of these libraries ported to C# in the next several months. Talking about reinventing the wheel. That's not reinventing the wheel, thats fitting the wheel to a different platform. I would suspect that most of the logic and details would remain the same. Now before you go and reply to try to make me understand your meaning of life try to understand I'm talking about generalities. Each app needs to evaluate itself on a case-by-case basis. In general most apps would benefit from the simplifing effect of being written in C#. Joel Lucsy (jjlucsy@concentric.net)
-
Isn't that something you're supposed to avoid if you want good performance? That's why game programmers publish tips such as allocating one enormous block of memory at startup then using it sort of like a stack. You can't do that in exactly the same way with C#, but then there are other ways to make things perform better -- and allocating, reallocating, and allocating some more isn't one of those ways. John
That's a bit different with a GC. allocation in a Garbage collection scheme is much faster than on a vanilla heap (rouchly : Heap - scan for a matching block, GC - increment a pointer) When assuming a "typical" program which has computational (and "allocational") hot spots mixed with idle sequences, a GC based system can "look" much faster. Of course there is still some overhead, so one big allocation will be faster than many small ones. And with constant CPU/Memory Managment load, a badly designed GC can push you into a worst case scenario that makes the whole thing as slow as a Java app ;P
-
Fazlul Kabir wrote: G. Suresh wrote: But in most applications you will not see any difference For smaller apps, you may be right, but when it comes to large scale mission critical apps, think twice. Why? I would think writing the app in a more "safe" way would override any pressing concerns for speed. Fazlul Kabir wrote: G. Suresh wrote: Also, this is usually a one time hit. Subsequent invocations are fast. But when my customers see my apps starting up slow for the first time, they won't probably know what will happen second time. The default is to JIT any code on a per-method basis, not the entire app at once. This should be fast enough out of the starting blocks. Fazlul Kabir wrote: G. Suresh wrote: WIN32 interop is not so bad with .NET. But would you want to write the extra interop specific code every time you invoke a Win32 API? First, you'd only need to write the interop code once. Two, most of the win32 api is already in the managed library. Fazlul Kabir wrote: G. Suresh wrote: There are definitely more free (and commercial libraries) available for C++ than for C#. But I think that we will see lots of these libraries ported to C# in the next several months. Talking about reinventing the wheel. That's not reinventing the wheel, thats fitting the wheel to a different platform. I would suspect that most of the logic and details would remain the same. Now before you go and reply to try to make me understand your meaning of life try to understand I'm talking about generalities. Each app needs to evaluate itself on a case-by-case basis. In general most apps would benefit from the simplifing effect of being written in C#. Joel Lucsy (jjlucsy@concentric.net)
Joel Lucsy wrote: Why? I would think writing the app in a more "safe" way would override any pressing concerns for speed. That's the price you pay. We're not supposed to talk about the performance comparison until the release is out, but from the bitter experience we already have from thick-client apps written using Java (even JIT'ed) in the past, we still need to see how pleasant our experience will be with C#. Joel Lucsy wrote: This should be fast enough out of the starting blocks. That's not the case in reality. You can try for yourself and compare with other native C++ app written using MFC/WTL. Joel Lucsy wrote: most of the win32 api is already in the managed library. It's not only Win32 API, but also the huge C/C++ repository we've already built over the last 20+ years. Joel Lucsy wrote: Each app needs to evaluate itself on a case-by-case basis. I agree on this, just like VB is not suitable for apps that should be written using C++. // Fazlul
Get RadVC today! Play RAD in VC++ http://www.capitolsoft.com