C++ with automatic garbage collection = C#
-
goto. *runs*
Stirrer :)
The only thing unpredictable about me is just how predictable I'm going to be.
-
PIEBALDconsult wrote:
No, it's part of .net.
Yeah but in a future version of the .NET framework, if it was a configurable option to turn off the GC (say via a GC::ShutDown() method), I am sure this wouldn't be a practical option for C#. Since C# does not have a syntactic equivalent of the C++ delete. You'd have to end up doing something weird like GCHandle::Delete(object) which would kill off C# popularity. So while GC is a part of .NET, people will always associate it with C#.
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
My latest book : C++/CLI in Action / Amazon.com linkAssociate all you want. It ain't part of C#
The only thing unpredictable about me is just how predictable I'm going to be.
-
Chris Losinger wrote:
GC is part of C# the same way vtables are part of C++. RegEx is an add-on in both
Nitpicking, one could say that is true. In the real world, C# doesn't really exist apart from the .NET framework. It's a bit like people assuming that MFC is part of C++, the difference is that in the C# world, there's no real world opposing viewpoint, no version of C# for which it's not true.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
Christian Graus wrote:
Nitpicking, one could say that is true. In the real world, C# doesn't really exist apart from the .NET framework.
I think that's the point (or anti-point .. lol). Just because it has a close tie with the Framework doesn't mean the language doesn't exist in its own right. And for that matter the Framework lives on regardless of the existence or not of C#.
Christian Graus wrote:
It's a bit like people assuming that MFC is part of C++, the difference is that in the C# world, there's no real world opposing viewpoint, no version of C# for which it's not true.
But I take your point yes. The basic problem with C# is the name and name alone. Most criticisms of the C# language that I have read always seem to hark back to a comparison with C++. Why I don't know. I was at one time C programmer (a very ordinary hobbyist). When I started developing for a living I worked mostly with Java as that was what my "house" was using. Now I'm freelancing I tend towards C#. There are more similarities between Java and C# than C++ and C#. It seems that the existence of the letter C at the beginning has does something to relate the languages. I've often wondered why the name C# was chosen and I'm afraid the only conclusion I can come to is that it was a marketing decision. Let's face it most C developers would naturally be drawn to investigate a language called C++. In the same way could it not be said that same could hold true for C#?
The only thing unpredictable about me is just how predictable I'm going to be.
-
Stroustrup was asked when Java came out what he thought of GC. His core answer was that GC would have killed C++, because of performance issues ( which may have been more real with the speed of processors then, than now ). There are a LOT of differences between C++ and C#. C++ has a better standard library, but C# offers support for things that C++ does not, such as regex. Yes, you can add those, I'm talking core language here. If anything, I think it's a shame C# looks like C++, when it's really very different in many ways.
deostroll wrote:
The result of this is that you are being pressurized, unnecessarily; or worse the customers themselves pressurizing you, unnecessarily!
Really, the issue is that your client has no idea how long software takes, and a strong idea of when they want it. Explain the development triangle to them. Features, time, reliability. You can have two. Tell me which one to sacrifice to get the other two done.
deostroll wrote:
Given indefinite time I believe developing applications in c++ would result in robust applications.
Given *reasonable* time, C++ results in robust applications.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
The only benefit of C# is the .net framework. Just like borlands VCL it is the framework and not the language (c++, delphi) that makes a technology worth while. Jan
-
Christian Graus wrote:
The C# team says they are aiming to make the language as easy as possible, which is the exact opposite of the goal of the C++ team ( make it as powerful as it can be ).
That's why I don't like C#. IMO they are creating a monster with the language. As an example, do the
yeild returnthing adds power? No. But it makes it easy. It reminds me of all this keywords they added to VB6 (not comparing both languages though). They are just making it fancier, instead of giving power to the programmer. However, I wish the C++ library had more features. A GUI, for example, would be very nice. And XML and networking support. I know that the main goal is to make it portable, thus there may be devices that couldn't support this features. But what the hell, for these cases, they don't have to fulfill the standard (e.g. Embedded VC++ 3 didn't support exception handling). Any way, I'm still looking forward the next version of the standard.
Hope is the negation of reality - Raistlin Majere
Fernando A. Gomez F. wrote:
Christian Graus wrote: The C# team says they are aiming to make the language as easy as possible, which is the exact opposite of the goal of the C++ team ( make it as powerful as it can be ). That's why I don't like C#. IMO they are creating a monster with the language. As an example, do the yeild return thing adds power? No. But it makes it easy. It reminds me of all this keywords they added to VB6 (not comparing both languages though). They are just making it fancier, instead of giving power to the programmer.
What about anonymous functions and LINQ? Those do give more power, don't they?
-
What is the real difference, you ask? It is there in the title itself. Plus you may argue that c# is more typesafe and stuff; avoids any usually complex pointer logic; avoids pointers totally...yada yada yada... To me it is just the way c# language compiler was designed. When you come down to the compiler level you have to de-initialize an object and clear memory. No other way to do this. It may be a mammoth task in c++, but it is possible. Everything is possible. Those who say something is impossible are probably out of ideas (or lack of sample code maybe :confused:). Given indefinite time I believe developing applications in c++ would result in robust applications. However what most programmers do today is charge into the arena like a bull! I'd rather like to plan my path. And a piece of paper and a pen that writes is always a good start. I wonder who the hell said: time is money. I'd want to throw my pc at him, and say thankyou very much! It is what people are asking for. It is our society. Most of the time when customers ask developers to do something, they completely drop the ethical sense. The result of this is that you are being pressurized, unnecessarily; or worse the customers themselves pressurizing you, unnecessarily! For if it was the opposite case (i.e. the customers had this ethical knowledge) and they kept pressurizing you, there would at least be some sort of justice/sense in that! (You being nailed to the wall here is not the point). --deostroll
Your simplification fails to grasp several key concepts that distinguish C++. I will just highlight one of these, because it is my favourite concept (and arguably the cornerstone to C++' success). I am speaking of templates. Yes, I know that C# has generics but these have not much in common with C++' powerful concept. C++ templates allow the implementation of very high abstraction data models and algorithms without any runtime penalty whatsoever! Take a look at any book on algorithms. Chances are, the examples are implemented in Java (unless, of course, you are reading Knuth, who, for reasons best known to himself, treats us to MIX). Now, these example codes usually practice a very high level of abstraction and present the concepts in a wonderfully concise way (once we overlook the shortcomings of Java's syntax). But, these books have a serious drawback: They trade abstraction for performance. Unfortunately, this trade-off is still (and will be for years to come) absolutely unacceptable in many computing areas. My own domain is bioinformatics and here the performance/abstraction trade-off of languages such as C#, VB or Java are clearly out of question. Templates in C++ offer the same degree of abstraction – in fact, the STL is a textbook example of abstraction and surpasses anything .NET or Java can muster – and the performance penalty (on modern compilers) equals zero. Good C++ compilers produce code having the same performance as hand-coded assembler routines, while using high abstraction. Stroustrup gives a very good example of the power of templates by comparing C++' std::sort function to qsort from C. Surprisingly, std::sort outperforms qsort even when their implementations are conceptually identical. This is due to the fact that qsort has to call a function pointer in order to compare elements. C++ achieves the same genericity through templates and a function object. This function object call can be inlined most of the time, eliding any runtime overhead. I have to address one other issue, though (because it figures in your thread title). C++ has no garbage collection for very good reasons. For those interested in details, I can advise looking up the RAII idiom and C++' way of treating objects as stack-located values most of the time (rather than working on pointers to the heap).
-
The only benefit of C# is the .net framework. Just like borlands VCL it is the framework and not the language (c++, delphi) that makes a technology worth while. Jan
For the most part I agree, but I've come across a number of cases where C#, for me, has nosed ahead over C++, and that is purely because of language features. The combination of delegates, events, and anonymous methods made implementing a number of low level systems that make no use of the framework (Except for the Delegate and Object classes :) ) The ease of using member functions as delegates is just so straight forward in C#, and using pointers to member functions in C++ is so incredibly painful without boost to help, it was a breath of fresh air. - Phil
-
Either way, what's the point of having different languages, that are all the same ?
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
The most important reason of all! To give us all something to argue about when it's raining outside :)
-
Your simplification fails to grasp several key concepts that distinguish C++. I will just highlight one of these, because it is my favourite concept (and arguably the cornerstone to C++' success). I am speaking of templates. Yes, I know that C# has generics but these have not much in common with C++' powerful concept. C++ templates allow the implementation of very high abstraction data models and algorithms without any runtime penalty whatsoever! Take a look at any book on algorithms. Chances are, the examples are implemented in Java (unless, of course, you are reading Knuth, who, for reasons best known to himself, treats us to MIX). Now, these example codes usually practice a very high level of abstraction and present the concepts in a wonderfully concise way (once we overlook the shortcomings of Java's syntax). But, these books have a serious drawback: They trade abstraction for performance. Unfortunately, this trade-off is still (and will be for years to come) absolutely unacceptable in many computing areas. My own domain is bioinformatics and here the performance/abstraction trade-off of languages such as C#, VB or Java are clearly out of question. Templates in C++ offer the same degree of abstraction – in fact, the STL is a textbook example of abstraction and surpasses anything .NET or Java can muster – and the performance penalty (on modern compilers) equals zero. Good C++ compilers produce code having the same performance as hand-coded assembler routines, while using high abstraction. Stroustrup gives a very good example of the power of templates by comparing C++' std::sort function to qsort from C. Surprisingly, std::sort outperforms qsort even when their implementations are conceptually identical. This is due to the fact that qsort has to call a function pointer in order to compare elements. C++ achieves the same genericity through templates and a function object. This function object call can be inlined most of the time, eliding any runtime overhead. I have to address one other issue, though (because it figures in your thread title). C++ has no garbage collection for very good reasons. For those interested in details, I can advise looking up the RAII idiom and C++' way of treating objects as stack-located values most of the time (rather than working on pointers to the heap).
RAII and templates - seconded. While templates make it exceedingly easy to make some ugly code, used appropriately they are one of the most powerful and under-appreciated tools I've seen. And RAII - gee I miss that living in .Net land. The using keyword just doesn't scratch the same itch for me.
-
Chris Losinger wrote:
GC is part of C# the same way vtables are part of C++. RegEx is an add-on in both
Nitpicking, one could say that is true. In the real world, C# doesn't really exist apart from the .NET framework. It's a bit like people assuming that MFC is part of C++, the difference is that in the C# world, there's no real world opposing viewpoint, no version of C# for which it's not true.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
Christian Graus wrote:
In the real world, C# doesn't really exist apart from the .NET framework.
i'm a little disappointed to see that two people decided, in all the crap i wrote, to focus on that one throwaway analogy. :) oh well
-
Associate all you want. It ain't part of C#
The only thing unpredictable about me is just how predictable I'm going to be.
read the spec: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf[^]. look up "garbage collection" - it's everywhere, it's non-optional, it's requirement of the langauge. now look up ".Net". there are three references: two in the first two paragraphs about the history of the language; and the other is in a code sample where the string ".Net" is part of an object specification. there's nothing in the spec that says "garbage collection is part of .Net, not C#". it is perfectly obvious that the people who wrote the C# spec think that GC is an intrinsic part of the C# language istelf.
-
read the spec: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-334.pdf[^]. look up "garbage collection" - it's everywhere, it's non-optional, it's requirement of the langauge. now look up ".Net". there are three references: two in the first two paragraphs about the history of the language; and the other is in a code sample where the string ".Net" is part of an object specification. there's nothing in the spec that says "garbage collection is part of .Net, not C#". it is perfectly obvious that the people who wrote the C# spec think that GC is an intrinsic part of the C# language istelf.
GC is part of the CLR From .NET Framework Essentials by Thuan Thai and Hoang Q Lam "Unlike C++, where you must delete all heap-based object manually, the CLR supports automatic lifetime management for all .NET objects. The garbage collector can detect when your objects are no longer referenced and perform garbage collection to reclaim the unused memory." This page talks about garbage collection in VB.NET http://www.dotnet-guide.com/garbagecollection.html Jeffrey Richter talks about it on Microsoft's site http://msdn.microsoft.com/msdnmag/issues/1100/gci/ Trust me it is part of the CLR. Sure C# references will talk about it, as do VB.NET, J#, etc etc. It is part of the CLR and hence inherent and pertinent to all .NET langauges.
The only thing unpredictable about me is just how predictable I'm going to be.
-
What is the real difference, you ask? It is there in the title itself. Plus you may argue that c# is more typesafe and stuff; avoids any usually complex pointer logic; avoids pointers totally...yada yada yada... To me it is just the way c# language compiler was designed. When you come down to the compiler level you have to de-initialize an object and clear memory. No other way to do this. It may be a mammoth task in c++, but it is possible. Everything is possible. Those who say something is impossible are probably out of ideas (or lack of sample code maybe :confused:). Given indefinite time I believe developing applications in c++ would result in robust applications. However what most programmers do today is charge into the arena like a bull! I'd rather like to plan my path. And a piece of paper and a pen that writes is always a good start. I wonder who the hell said: time is money. I'd want to throw my pc at him, and say thankyou very much! It is what people are asking for. It is our society. Most of the time when customers ask developers to do something, they completely drop the ethical sense. The result of this is that you are being pressurized, unnecessarily; or worse the customers themselves pressurizing you, unnecessarily! For if it was the opposite case (i.e. the customers had this ethical knowledge) and they kept pressurizing you, there would at least be some sort of justice/sense in that! (You being nailed to the wall here is not the point). --deostroll
I agree on the templates. In C++ the type system is more or less Turing complete - in C# you just get generics. Also, C++ has multiple inheritance, C# does not. I know this was a design decision but more than once I have started something in C# and switched back to C++ for lack of this mechanism. The perception that C# takes less time to write programs in generally just comes down to the library you get. If a really good, object-oriented framework were released for C++ I think some people would realize just how simple it can be. The difficult thing is creating the tools that can be used to get there. In terms of GC, in my experience manual deletion doesn't get too out-of-hand. In terms of noticeably slowing down development I'd say more time would be spent deciding what path to take to solve a tricky problem. Most memory management can be integrated into classes that know what kind of data they're dealing with. The real problem here is that too many libraries don't leverage this utility - personally I hate calling something like RegQueryValueEx with null parameters, allocating a string then calling it again just to map a registry path to a value. Surely the system should be able to do this itself, after all there are plenty of windows API functions for memory management. In talking about power, some things do expand the power of C++. The yield stuff, IMO, actually does give C# something C++ doesn't have. Assuming this is implemented how I would expect (context switches/coroutines/fibers), this allows efficiency to be achieved in some situations, in that state information for your collection or whatever is maintained implicitly on another stack. Abstracting this in C++ is possible, but needs quite a bit of effort, especially with the Win32 CreateFiber, etc. routines. As for anonymous functions and LINQ, I don't think they really make C# more powerful. LINQ certainly not. I think it's a horrible idea - integrating an application-specific feature into what is supposed to be a standardized programming language, which in essence just redirects your queries and such - does not make it more powerful at all. Anonymous functions add a little bit I think, and are certainly useful - but what they usually do can be achieved in other ways, with just a bit more boilerplate code. Lambda functors have been implemented in C++ with some utility (in Boost, unsurprisingly), so this becomes trivialized. That C++ is able to implement things like this in a library (albeit somewhat awkwardly), and C# (to date) can't or won't show
-
What is the real difference, you ask? It is there in the title itself. Plus you may argue that c# is more typesafe and stuff; avoids any usually complex pointer logic; avoids pointers totally...yada yada yada... To me it is just the way c# language compiler was designed. When you come down to the compiler level you have to de-initialize an object and clear memory. No other way to do this. It may be a mammoth task in c++, but it is possible. Everything is possible. Those who say something is impossible are probably out of ideas (or lack of sample code maybe :confused:). Given indefinite time I believe developing applications in c++ would result in robust applications. However what most programmers do today is charge into the arena like a bull! I'd rather like to plan my path. And a piece of paper and a pen that writes is always a good start. I wonder who the hell said: time is money. I'd want to throw my pc at him, and say thankyou very much! It is what people are asking for. It is our society. Most of the time when customers ask developers to do something, they completely drop the ethical sense. The result of this is that you are being pressurized, unnecessarily; or worse the customers themselves pressurizing you, unnecessarily! For if it was the opposite case (i.e. the customers had this ethical knowledge) and they kept pressurizing you, there would at least be some sort of justice/sense in that! (You being nailed to the wall here is not the point). --deostroll
In order to lay the groundwork for reasonable comparison, I'll make an assumption that we're comparing MS C++ vs MS C#. With that assumption, we can now follow with the evidence of the case: C# was designed for use with the .NET framework (by MS), and their desire to push this framework to the exclusion of any other would lead to some logical business decisions: . Push C# by making it as feature-rich as possible. . Push C# by making its competition, even though part and parcel to the same IDE, lacking. . Further abetting this via the insidious MS Help - the world standard in negligant pathos. Most of the time we are not coding into the deep realms exposed by C/C++, but are busily using the various canned methods. By not giving help and support for one language, and pouring it on for the other, they are, again, herding their perspective sheep. C/C++, as was pointed out in one of the many other posts, pre-supposes adequate (and well folded) grey matter between the ears. This, it would seem, is becoming an ever more difficult commodity to procure. In addition, the clever ones often move off into the dreadful realm of OPEN SOURCE developmen! Competition. How awful. So, as I learned some years ago, MS's MapPoint objects were supported in VB, but not VC++, we have an agenda to consider. What this is about is MS spreading "their fertilizer" on the C# lawn, making the grass greener. What will happen when all (or close enought to all) of the sheep move to that greener pasture, is that they'll find themselves up to their ankles in that fertilizer - whilst standing upon their head. I still bang into that wall - using the Word SpellCheck required calling a method with ca. 15 arguments. It was left as an exercise for me to determine that the type 'Missing' needed to be used in all but one of them). This appears to have come out as some sort of rant, but my paranoia about MS's goals and strategies lead me down the path that they don't do these things by accident. I'd even bet that the Vista fiasco was taken into their planning . . .
-
GC is part of the CLR From .NET Framework Essentials by Thuan Thai and Hoang Q Lam "Unlike C++, where you must delete all heap-based object manually, the CLR supports automatic lifetime management for all .NET objects. The garbage collector can detect when your objects are no longer referenced and perform garbage collection to reclaim the unused memory." This page talks about garbage collection in VB.NET http://www.dotnet-guide.com/garbagecollection.html Jeffrey Richter talks about it on Microsoft's site http://msdn.microsoft.com/msdnmag/issues/1100/gci/ Trust me it is part of the CLR. Sure C# references will talk about it, as do VB.NET, J#, etc etc. It is part of the CLR and hence inherent and pertinent to all .NET langauges.
The only thing unpredictable about me is just how predictable I'm going to be.
SimonRigby wrote:
Sure C# references will talk about it
i'm pretty sure the official spec is the authoritative reference, in this case.
SimonRigby wrote:
Trust me it is part of the CLR.
you're arguing against something i never said. the details of the implementation of GC in MS's C# package, and its relation to other .Net languages is a separate issue from the fact that GC is an intrinsic part of the C# language itself.
SimonRigby wrote:
It is part of the CLR and hence inherent and pertinent to all .NET langauges.
again, the fact that the GC in MS's implementation of C# comes from the same place that VB's GC comes from does not in any way mean that GC is not part of the C# language itself.
-
PIEBALDconsult wrote:
More importantly all the CLI languages share one standard library.
So ?
PIEBALDconsult wrote:
The worst, in my opinion, is switch statements.
Far from the worst, but it is a disaster. The C# team says they are aiming to make the language as easy as possible, which is the exact opposite of the goal of the C++ team ( make it as powerful as it can be ).
PIEBALDconsult wrote:
Things would be so much better if break didn't affect switch at all
It would be more obvious. But, the C++ way is better, because it assumes I have half a brain, and it gives me more power to write good code.
PIEBALDconsult wrote:
I'm waiting for the next language that will learn from C#'s shortcomings.
It is indeed unfair to compare C++ and C#, excepting where C# fails and C++ succeeds, because it makes no sense to suggest that a language that came out 10 years later ( or whatever it is ) would not take the time to learn from the mistakes of what came before.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
A long while ago, when Chuck Yeager was giving lectures at the Air and Space museum. He was asked which plane he liked the best from someone in the audience. At the time the B1B was being deployed and he participated in its testing, the plane was also in the news. A person in the audience gave him a choice between the B1B and the SR71. He said hands down the SR71. He said the B1B had so much automation in it that if you wanted the jet to perform beyond it’s performance envelope you would be overruled by the on board computer. On the other hand if you wanted to, you could break an SR71 in half by pushing it too hard… and he was willing to take the chance of breaking a plane in half to get away from the bad guys. C# is a B1B. C++ is an SR71.
MrPlankton
-
SimonRigby wrote:
Sure C# references will talk about it
i'm pretty sure the official spec is the authoritative reference, in this case.
SimonRigby wrote:
Trust me it is part of the CLR.
you're arguing against something i never said. the details of the implementation of GC in MS's C# package, and its relation to other .Net languages is a separate issue from the fact that GC is an intrinsic part of the C# language itself.
SimonRigby wrote:
It is part of the CLR and hence inherent and pertinent to all .NET langauges.
again, the fact that the GC in MS's implementation of C# comes from the same place that VB's GC comes from does not in any way mean that GC is not part of the C# language itself.
I get the feeling this is going nowhere. I concede, you win :) (pssst .. its part of the CLR)
The only thing unpredictable about me is just how predictable I'm going to be.
-
A long while ago, when Chuck Yeager was giving lectures at the Air and Space museum. He was asked which plane he liked the best from someone in the audience. At the time the B1B was being deployed and he participated in its testing, the plane was also in the news. A person in the audience gave him a choice between the B1B and the SR71. He said hands down the SR71. He said the B1B had so much automation in it that if you wanted the jet to perform beyond it’s performance envelope you would be overruled by the on board computer. On the other hand if you wanted to, you could break an SR71 in half by pushing it too hard… and he was willing to take the chance of breaking a plane in half to get away from the bad guys. C# is a B1B. C++ is an SR71.
MrPlankton
5 for the Yeager! He's the other "Chuck" ;).
- S 50 cups of coffee and you know it's on!
-
I get the feeling this is going nowhere. I concede, you win :) (pssst .. its part of the CLR)
The only thing unpredictable about me is just how predictable I'm going to be.
SimonRigby wrote:
I concede, you win
Victory! :jig:
-
A long while ago, when Chuck Yeager was giving lectures at the Air and Space museum. He was asked which plane he liked the best from someone in the audience. At the time the B1B was being deployed and he participated in its testing, the plane was also in the news. A person in the audience gave him a choice between the B1B and the SR71. He said hands down the SR71. He said the B1B had so much automation in it that if you wanted the jet to perform beyond it’s performance envelope you would be overruled by the on board computer. On the other hand if you wanted to, you could break an SR71 in half by pushing it too hard… and he was willing to take the chance of breaking a plane in half to get away from the bad guys. C# is a B1B. C++ is an SR71.
MrPlankton
