C++ with automatic garbage collection = C#
-
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.
-
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.
deltalmg wrote:
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.
More than the compiler writers, the library writers. In the end, this has already been done. Take the Qt library as an example. Other languages and platforms have done the same (i.e. Java and the .NET Framework).
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.
Oh wait, this one's better: " Automatic memory management is one of the services that the common language runtime provides " http://msdn2.microsoft.com/en-us/library/f144e03t(VS.71).aspx[^]
-
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.
PIEBALDconsult wrote:
But they're not the ones who define the language, Microsoft is
ugh. be serious. the document you link to says, in the second sentence: "C# is standardized by ECMA International as the ECMA-334". that's the exact document that i linked to above. that's the official language specification, and MS submitted it to the ECMA in 2001 for adoption as the standard.
PIEBALDconsult wrote:
C# assumes there is a GC, just like it might assume there is a file system or console.
"assume" does not mean "prefer". there's no way to read that spec and conclude that GC is optional.
-
Oh wait, this one's better: " Automatic memory management is one of the services that the common language runtime provides " http://msdn2.microsoft.com/en-us/library/f144e03t(VS.71).aspx[^]
PIEBALDconsult wrote:
this one's better
better for what ? what are you trying to prove ? i've never said GC in MS's C# package isn't provided by the CLR. i've always said that GC is an intrinsic part of C#: that C# requires it; that it is part of what makes C# the language that it is. the specifics of MS's implementation are utterly irrelevant to what i've been saying in this thread.
-
PIEBALDconsult wrote:
this one's better
better for what ? what are you trying to prove ? i've never said GC in MS's C# package isn't provided by the CLR. i've always said that GC is an intrinsic part of C#: that C# requires it; that it is part of what makes C# the language that it is. the specifics of MS's implementation are utterly irrelevant to what i've been saying in this thread.
Oh, then we're in violent agreement... but someone said it was...
-
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. 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.
Not really. I don't believe that anyone would claim that the C# keyword "partial" is part of a library. It completely and solely part of the language. Conversely you can't do regexes in C, C++, java or C# without a library. Matter of fact you can't do anything practical at all in C, C++, java or C# without a library. That isn't true of Perl. Both regexes and quite a bit of other functionality which the other languages lack is supported directly by the language itself. Yet there are a wide variety of libraries for it some of which are part of the "definition" of language itself. And I don't believe the Forth language isn't even Turing complete without a library. So it is certainly relevant to discuss whether a language supports something or not directly. Particularly when that is exactly what the discussion is about.
-
what's wrong with this one[^]? although, i believe that the well designed C++ program should extremely rarely exhibit problems with memory issues. The problem is that many devevelopers still write C using C++ compilers, so they malloc/free or new/delete bunch of stuff. I don't see why anyone would allocate memory for an array on the heap if there is std::vector. why would you explicitly delete something if you have std::auto_ptr or some smart pointer implementation (e.g. boost::shared_ptr)? Of course, i am aware that there are situations where you have to go 'classic' way, but that is minority, IMO.
-
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).
KLMR wrote:
Unfortunately, this trade-off is still (and will be for years to come) absolutely unacceptable in many computing areas.
Presumably you mean as a absolute count rather than in comparison to all software fields. Because in comparison performance problems causes by data structure layout itself in all of software is so small that it is probably unmeasurable. It would certainly be insignificant.
KLMR wrote:
and the performance penalty (on modern compilers) equals zero.
You are claiming that data constructs in C++ have a zero cost? That is incorrect. Certainly chosing the wrong one can impact the application. And if a particular construct is a bottleneck, which your other comments suggest that you always see, then considering a custom implementation based on knowledge of the actual data and flow can provide a performance improvement over the generic types - which again suggests that there is a cost.
KLMR wrote:
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).
As far as I can tell both of those assertions are wrong. In terms of original creation of C++ garbage collection probably wasn't considered at all. That would be the reason for not having it. Another reason would have been because C didn't have it. Other than that it is like many other additional features in C++, it one wants it then one can add it. As Stroustrup says.... http://www.research.att.com/~bs/bs_faq.html#garbage-collection[^] Secondly exactly what source leads you to believe that "most" value entities in C++ live on the stack versus the heap? And more importantly what makes you think that is the case for objects versus primitive types? (I don't really consider the consideration of such things as for loop index variables as valid candidates for this since no one is going to ever create those on the heap anyways.)
-
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 am askin' myself !!! what I do need tones of libraries and spaghetized frameworks to open a file or a socket or a stream or to write some code? I dont. C++ was made by THE ONE for THE ONE. C# was made by the ONES for the OTHERS that's why it wont stand a chance to C++. I don't say C# does not have it's buddies but they will leave-it as soon next language will be invented by some Mammoth company. They already know that couse' they have been to so many ...VB, Java, and now C# and C(bemol)..who knows...
-
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 )
I am askin' myself !!! what I do need tones of libraries and spaghetized frameworks to open a file or a socket or a stream or to write some code? I dont. C++ was made by THE ONE for THE ONE. C# was made by the ONES for the OTHERS that's why it wont stand a chance to C++. I don't say C# does not have it's buddies but they will leave-it as soon next language will be invented by some Mammoth company. They already know that, 'couse they have been to so many prior' ...VB, Java, and now C# and C(weak)..who knows...
-
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 think you've got a good grasp of the situation. In a way, it's interesting for me to read threads like this . I am not a professional programmer. What I am is a professional currency trader. All programming I do, and believe me I do a lot, is to that end. So I read these conversations...'this is better than that...my brain is bigger than yours' with a bit of amusement. The bottom line is that software is a tool, period. The software is the servant, not the master. BW ------------------------------------------------------ The natural state of man is trust, not skepticism.
-
Zdeslav Vojkovic wrote:
I don't see why anyone would allocate memory for an array on the heap if there is std::vector.
And where exactly does the std:vector live?
vector's storage does live on heap, however, vector itself usually lives on stack (of course, depending on how you use it), so its destruction is deterministic, and that is what is important here. From your other posts, i believe you are aware of RAII idiom, which is a very powerful kind-of-replacement for GC (yes, i am aware of differences), and more generic (because, unlike GC, with RAII you can also handle other resources, like DB connections, GDI objects, etc). the point here is that, if you use STL (and/or some extensions) properly, you don't need GC in C++ for most tasks, and need for GC is the topic of this thread.