C++ with automatic garbage collection = C#
-
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
-
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
Anonymous delegates and generic methods are very powerful. Combined with reflection and you can do some really good things here, without much code. A lot of people are concerned about LINQ, but it looks very good also. And although it's not part of the actual language, the TPL MSFT is developing looks very promising. ---------------------------------------------- Man's natural state is trust, not suspicion.
-
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
Pirate Jonno wrote:
If a really good, object-oriented framework were released for C++ I think some people would realize just how simple it can 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
There are a lot of other differences. C# is more elegant in many subtle ways. For example, adding event handlers in C++ is awkward when you want to add an uncommon one. In C# you can easily add anything. (Haven't tried managed C++ yet; it may be different.) There are other differences that are hard to quantify, such as reliability of the implementation. Many features in C++/MFC simply don't work, making tasks that should take minutes take days. This is rare in C# .NET. The .NET classes are more complete and logical. The MFC CBitmap class didn't even have a method to read a bitmap from a file! (Again, this is more an MFC issue, and may be moot with C++ .NET.)
-
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?
I... couldn't say. I'm still stucked with C# 2.0, and haven't had the chance to look to C# 3.
Hope is the negation of reality - Raistlin Majere
-
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:
They are just making it fancier, instead of giving power to the programmer.
Yes and no. By adding keywords to the language, they are ensuring that common tasks are done in a consistant manner. As an added bonus you get to do with one command, what others are proposing you create a new method for. Method calls have overhead, and in general screw with optimization. Stroustrup has claimed on many occasions that C++ is for "large systems". Hate to say it, but the vast majority of "large systems" aren't very GUI intensive. If your coding with VS anyways, you can do your gui's that way, or even use managed regions of your C++ code and call the other .Net languages to handle your GUI for you. If you want cross platform GUI's in straight C++ use Qt or something similar. The C++ standard commitee should focus on core functionality of the language, people interested in GUI's should code libraries, or use someone elses libraries. Heck the .Net languages don't really have GUI's built into the language, they have rappers around the Win32 dlls that implement the GUI's (which are written in C++).
-
Fernando A. Gomez F. wrote:
They are just making it fancier, instead of giving power to the programmer.
Yes and no. By adding keywords to the language, they are ensuring that common tasks are done in a consistant manner. As an added bonus you get to do with one command, what others are proposing you create a new method for. Method calls have overhead, and in general screw with optimization. Stroustrup has claimed on many occasions that C++ is for "large systems". Hate to say it, but the vast majority of "large systems" aren't very GUI intensive. If your coding with VS anyways, you can do your gui's that way, or even use managed regions of your C++ code and call the other .Net languages to handle your GUI for you. If you want cross platform GUI's in straight C++ use Qt or something similar. The C++ standard commitee should focus on core functionality of the language, people interested in GUI's should code libraries, or use someone elses libraries. Heck the .Net languages don't really have GUI's built into the language, they have rappers around the Win32 dlls that implement the GUI's (which are written in C++).
deltalmg wrote:
By adding keywords to the language, they are ensuring that common tasks are done in a consistant manner.
But in the example of a
yield return, I can't see the "consistant manner" you speak of. It is just a shortcut to creating an IEnumerable-derived object and return it.deltalmg wrote:
what others are proposing you create a new method for. Method calls have overhead, and in general screw with optimization.
Although I haven't seen MSIL, I bet that the code of the
yield returnis translated into creating an IEnumerable-derived object, add new items and return it. Same thing for theparams, just collect the multiple parameters into an array. Same thing for theforeach. Do they have any specific optimization? If so, then they would be justified.deltalmg wrote:
The C++ standard commitee should focus on core functionality of the language, people interested in GUI's should code libraries, or use someone elses libraries.
This is true not only for GUIs but for anything else in the standard library. People interested in fast generic data structures and algorithms should code libraries or use someone else's. However, since these things are used a lot in most of the systems, the commitee decided to include them as part of the standard library. Why? Because it was (is) very useful to most of the applications for most of the OSes. Why not do the same for GUIs? A standarized way for creating graphical applications. No need to depend on provider's whims (whether Microsoft will change this or that on MFC, or if WTL is no longer supported, or if Qt is free only for open source applications). Having a standarized GUI library as part of the C++ Standard Library is one of my wishes, as well as having a standarized ABI for DLLs.
Hope is the negation of reality - Raistlin Majere
-
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 to this extent: if you can get a team of individually near-perfect programmers who work even better together, C++ is the way to go. The control it gives you is not matched in any of the other .NET development environments. However, in the real world...back in 1994 my former boss and at-that-time client asked me what language to use for his new employee benefits administration system. Because he and I had worked together for six years on megabytes of codes written in C, he was surprised when instead of C/C++ I recommended Visual Basic. Naturally, he asked why. I replied, "Because they're cheap and easily disposed." Languages for the elite must be programmed by the elite, and the elite are always in short supply. Granted, with the right three people I could outperform any ten basic coders, but with three basic coders and me writing specs and all of us reviewing code and tests I can generate a working implementation very quickly. This is the primary delivery criterion for business software, as changes in the needs of the business require rapid delivery of changes in the software. It stands as a corollary that any really life-critical system is built in C/C++ or some other language that offers equal control of the programming environment, and it is written only after a great deal of thought has gone into the initial design and the design of any new releases. It all depends on the priorities you are required to recognize. Christopher P. Kile "Nothing is wasted if you keep looking for another use for it."
-
I... couldn't say. I'm still stucked with C# 2.0, and haven't had the chance to look to C# 3.
Hope is the negation of reality - Raistlin Majere
Fernando A. Gomez F. wrote:
I... couldn't say. I'm still stucked with C# 2.0, and haven't had the chance to look to C# 3.
Anonymous functions have been introduced in C# 2.0, as well generics and partial types. Looks to me that you aren't quite uptodate with the evolution of C# as you thought originally.
-
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.
It's part of the CLR; all CLR languages benefit from it. There are no C# keywords to control it, it is not part of the language. " The .NET Framework's garbage collector manages the allocation and release of memory for your application. " (Emphasis added) http://msdn2.microsoft.com/en-us/library/0xy59wtx.aspx[^]
-
deltalmg wrote:
By adding keywords to the language, they are ensuring that common tasks are done in a consistant manner.
But in the example of a
yield return, I can't see the "consistant manner" you speak of. It is just a shortcut to creating an IEnumerable-derived object and return it.deltalmg wrote:
what others are proposing you create a new method for. Method calls have overhead, and in general screw with optimization.
Although I haven't seen MSIL, I bet that the code of the
yield returnis translated into creating an IEnumerable-derived object, add new items and return it. Same thing for theparams, just collect the multiple parameters into an array. Same thing for theforeach. Do they have any specific optimization? If so, then they would be justified.deltalmg wrote:
The C++ standard commitee should focus on core functionality of the language, people interested in GUI's should code libraries, or use someone elses libraries.
This is true not only for GUIs but for anything else in the standard library. People interested in fast generic data structures and algorithms should code libraries or use someone else's. However, since these things are used a lot in most of the systems, the commitee decided to include them as part of the standard library. Why? Because it was (is) very useful to most of the applications for most of the OSes. Why not do the same for GUIs? A standarized way for creating graphical applications. No need to depend on provider's whims (whether Microsoft will change this or that on MFC, or if WTL is no longer supported, or if Qt is free only for open source applications). Having a standarized GUI library as part of the C++ Standard Library is one of my wishes, as well as having a standarized ABI for DLLs.
Hope is the negation of reality - Raistlin Majere
Fernando A. Gomez F. wrote:
Why not do the same for GUIs? A standarized way for creating graphical applications. No need to depend on provider's whims (whether Microsoft will change this or that on MFC, or if WTL is no longer supported, or if Qt is free only for open source applications). Having a standarized GUI library as part of the C++ Standard Library is one of my wishes, as well as having a standarized ABI for DLLs.
It would be nice, however, what would end up being done, is the compiler writers would have to figure out how the innards of each OS's GUI API works and compile the standard C++ calls into the appropriate MFC/X11 etc calls. I have great respect for compiler writers, in my opinion they are some of the most technically skilled coders in the world. It would be a shame to force them to spend their time learning the ins and outs of a miriad of GUI API's that they have no control over. They'd end up running around like squirrels trying to keep up with OS changes, rather than concentrating their very mathmatical minds, on the challenges in their own field. I like things the way they are now. Let the OS vendors supply the API. They have the most interest, as they want your program running on their OS to help there sales, and they have the most knowledge of the innards of their system.
-
I agree to this extent: if you can get a team of individually near-perfect programmers who work even better together, C++ is the way to go. The control it gives you is not matched in any of the other .NET development environments. However, in the real world...back in 1994 my former boss and at-that-time client asked me what language to use for his new employee benefits administration system. Because he and I had worked together for six years on megabytes of codes written in C, he was surprised when instead of C/C++ I recommended Visual Basic. Naturally, he asked why. I replied, "Because they're cheap and easily disposed." Languages for the elite must be programmed by the elite, and the elite are always in short supply. Granted, with the right three people I could outperform any ten basic coders, but with three basic coders and me writing specs and all of us reviewing code and tests I can generate a working implementation very quickly. This is the primary delivery criterion for business software, as changes in the needs of the business require rapid delivery of changes in the software. It stands as a corollary that any really life-critical system is built in C/C++ or some other language that offers equal control of the programming environment, and it is written only after a great deal of thought has gone into the initial design and the design of any new releases. It all depends on the priorities you are required to recognize. Christopher P. Kile "Nothing is wasted if you keep looking for another use for it."
cpkilekofp wrote:
if you can get a team of individually near-perfect
... monkeys, you'd save money on salary and benefits.
-
It's part of the CLR; all CLR languages benefit from it. There are no C# keywords to control it, it is not part of the language. " The .NET Framework's garbage collector manages the allocation and release of memory for your application. " (Emphasis added) http://msdn2.microsoft.com/en-us/library/0xy59wtx.aspx[^]
PIEBALDconsult wrote:
it is not part of the language.
you'd better tell that to the authors of the C# language specification! i'm sure they'll be very embarrassed by their error.
-
cpkilekofp wrote:
if you can get a team of individually near-perfect
... monkeys, you'd save money on salary and benefits.
*shrugs* Carp if you want. The only times I've ever had memory leaks in C/C++ after my first two years of development, I traced them to library routines which had poorly-documented memory allocations (I was the wiener who walked around with "Essential C++", and I took great glee in pointing out how particular bugs could have been avoided by adhering to its principles). I believe this should demonstrate that I am capable of understanding your point - in fact I do, and sympathize; I think you should try to understand that no business that doesn't have to wants to be dependent on the skills of someone they can't easily replace. I knew this, and furthermore I knew that any potential investors would have this concept firmly in mind. Also, I didn't have a cadre of skilled C++ consultants I could recommend to him, and he didn't have time or the money to have me do it. I never shirk from telling my client or my boss the brutal truth. As a result, my client's company survived on VB consultants, many of them for less than six months each, until he got investors, built his business, and sold it. He made a lot of money because I told him the truth, and he listened. Think about it. Christopher P. Kile "Nothing is wasted if you keep looking for new uses for it."
-
Fernando A. Gomez F. wrote:
I... couldn't say. I'm still stucked with C# 2.0, and haven't had the chance to look to C# 3.
Anonymous functions have been introduced in C# 2.0, as well generics and partial types. Looks to me that you aren't quite uptodate with the evolution of C# as you thought originally.
:-O I was aware of generics and partial types, but nothing about anonymous functions. Thanks for pointing that out. On generics, I think that they did a great job, I really like how the C# team worked out the problems that C++ had with templates (e.g. not being able to distribute it in a binary, but only in a header file). However, the partial types... I don't see a reason to use them other than the IDE's management of the generated code.
Hope is the negation of reality - Raistlin Majere
-
PIEBALDconsult wrote:
it is not part of the language.
you'd better tell that to the authors of the C# language specification! i'm sure they'll be very embarrassed by their error.
All the way to the bank. But they're not the ones who define the language, Microsoft is: http://msdn2.microsoft.com/en-us/vcsharp/aa336809.aspx[^] Page 74: " Like other languages that assume the existence of a garbage collector, C# is designed so that the garbage collector may implement a wide range of memory management policies. " C# assumes there is a GC, just like it might assume there is a file system or console.
