C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Garbage Collection - The Trash Begins To Pile Up Goto page 1, 2, 3 ... 10, 11, 12  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Le Chaud Lapin Guest Posted: Wed Dec 27, 2006 10:10 am    Post subject: Garbage Collection - The Trash Begins To Pile Up The purpose of this post is to provide a bit of empirical evidence that GC is no panacea, and that adding it to C++ might do more harm than good. A while ago, I initiated a thread in comp.lang.c++.moderated called "Garbage Collection - Stop Making Trash!". In that thread, some of us argued, yet again, that adding garbage collection to C++ would seriously degrade the integrity of the language. For GC proponents, our arguments were insufficient, especially those who had deep experiences with/vested interest in languages like C++/CLI and C#. Some of these people also failed to see anything wrong with referring to C++/CLI as "Pure C++" though that has finally been rectified by renaming the "Pure C++" column, "Netting C++" http://msdn.microsoft.com/msdnmag/issues/06/08/nettingc/default.aspx What I have noticed over the past 6 months is something peculiar that one would never expect from the world of GC. Every article related to ..NET or C# that I have seen has had to do with 1. memory management 2. resource cleanup. For example, the web start page of the Visual Studio 2005 IDE formerly linked here: http://msdn.microsoft.com/msdnmag/issues/06/08/nettingc/default.aspx The beginning of this article states: "A garbage-collected heap has deep ramifications for destructors, and that's where we'll start." "Deep ramifications." That's strange. I thought the purpose of GC was to relieve the programmer of thinking about deep ramifications. There have been numerous such articles popping up over the past 6 months. I saw four in the same afternoon two weeks ago. One colleague had a memory management issue that had something to do with an object not going away when he wanted it to and asked me to help. As my GC experience is limited to Lisp, I could not, but I vaguely remember arriving at the conclusion based on his description of C#'s memory management model that there was nothing he could do - he was at the mercy of the GC. Another colleague of mine who abandoned C++ in favor C# for a year finally came back to the land of deliberate form and declared, "...well...I still like C# for GUI development, but you get what you pay for. You have to architect your code right no matter which language you use. Garbage collection simply makes it more difficult to find where bad code is being bad." Another example is the current Visual Studio 2005 IDE start page: http://msdn.microsoft.com/msdnmag/issues/06/11/CLRInsideOut/default.aspx "Uncovering and correcting memory issues in managed applications can be difficult. " That sentence says it all. This is written written by a company that had full control over the garbage collection system of a language it created. Unlike C++, they had absolute control over the the memory management system to mold it as they saw fit. Yet, when a programmer uses the GC model, they might experience the following problems: * An OutOfMemoryException is thrown. * The process is using too much memory for no obvious reason that you can determine. * It appears that garbage collection is not cleaning up objects fast enough. * The managed heap is overly fragmented. * The application is excessively using the CPU. All of these symptoms make me wary, but the second (*) is most impressive... "for no obvious reason that you can determine". The last word in this sentence, "determine", is closely related to another word, "determinism", a feature of C++ that is probably the basis for having never experienced any of these problems in C++. -Le Chaud Lapin- -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Stephen Howe Guest Posted: Wed Dec 27, 2006 11:15 pm    Post subject: Re: Garbage Collection - The Trash Begins To Pile Up Quote: A while ago, I initiated a thread in comp.lang.c++.moderated called "Garbage Collection - Stop Making Trash!". In that thread, some of us argued, yet again, that adding garbage collection to C++ would seriously degrade the integrity of the language. For GC proponents, our arguments were insufficient, especially those who had deep experiences with/vested interest in languages like C++/CLI and C#. Some of these people also failed to see anything wrong with referring to C++/CLI as "Pure C++" though that has finally been rectified by renaming the "Pure C++" column, "Netting C++" http://msdn.microsoft.com/msdnmag/issues/06/08/nettingc/default.aspx Your post is interesting, particularly the articles of what happening in the ...NET world concerning memory management and RC. And I agree with you on the damage of adding GC to C++. But I regard it as alarmist, the addition of GC to C++ will _never_ happen except as an optional component which was Bjarne's original vision (and to date in tihs newsgroup, I have never seen a GC aficionado talk about the optionality of GC for C++ which leads me to believe they regard it as compulsory). Optional I can live with. At this point it becomes political in whether the "option" is purely by the programmer as well as the vendor. Cheers Stephen Howe -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Guest Posted: Wed Dec 27, 2006 11:19 pm    Post subject: Re: Garbage Collection - The Trash Begins To Pile Up Le Chaud Lapin wrote: Quote: The purpose of this post is to provide a bit of empirical evidence that GC is no panacea, and that adding it to C++ might do more harm than good. Most of the problem is that 'Automatic GC" always seems to imply this feature -- the collected trash is always free store memory that may have cyclic references or pointers. However, but time and time again we rediscover that cyclic object references always imply that you cannot have deterministic destructors, because cycles themselves cannot be reclaimed deterministically, but must wait for a "cycle detecting agent." And we all know by now that the vast majority of resources must be handled in a deterministic fashion. Imagine not freeing file or socket handles, until you've exhausted the system - this is the strategy that "Automatic GC" takes with your memory. The truth of the matter is that C++ DOES have automatic garbage collection. The difference is that the C++ version uses a stack based semantic - it takes out the trash in the same way that your call stack has done for 40 some years. (Ironically, back then Stack based GC was the center of controversy. Go figure.) So if you really don't need 1 . cycles of pointers, and the cases where you do want this are very well understood, and there are now standard ways of dealing with it, and, 2. you are careful about the life of references passed as return values (something "Automatic GC" does solve) then C++ coupled with RAII is a far superior solution to the strategy Java / C# uses. So just what is the point of adding the feature that we don't have to worry about heap memory cycles and disappearing references every so often, but now we have to manually manage every other resource, worry about zombie objects (disposed but still alive otherwise) and worry about processes using 2GIGs of memory because the GC engine wasn't manually invoked after all??? The only reason I can see for trying to stuff Cyclic Heap Memory GC into C++ Stack based model is for integration with platforms that use these style heap management, i.e. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1956.pdf But even here there is no real reason you could not just override operators new / delete to use the systems heap in the traditional way. Who needs the "Dispose" pattern when you have destructors??? -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top bruno_pages Guest Posted: Wed Dec 27, 2006 11:32 pm    Post subject: Re: Garbage Collection - The Trash Begins To Pile Up My 'deep' experiences with the garbage collectors was also made with Lisp many years ago. At this time I work on a project named MAIA whose include the implementation of Common Lisp. One year before starting with this project, in fact during my DEA (Bac + 5 study in France) I write a small Lisp on Goupil, and obviously I implemented a GC : the mark & sweep. As I know there are several ways to implement a GC : - the mark & sweep : when there is no available memory block for an allocation, the still reached memory blocks are search in the memory, registers and stack. The non reached memory is collected to be placed in the heap. The reached memory is unchanged. As you can understand this create hole in the memory when the allocated block have different sizes. Obviously during the GC the application is stopped. - the stop and copy : the memory is divided by two, at a given moment only one half is used. When there is no available memory block for an allocation, the still reached memory blocks are search in the memory, registers and stack and moved from the current half memory to the other one. The disavantage is to divide the memory by two, but after each GC there is no hole in the memory because the still used memory blocks are packed. Obviously during the GC the application is stopped. - the incremental stop & copy : this GC use the assumption "generally an allocated object become unused very soon or has a long life". This GC is an extension of the stop & copy, the memory is not divided by two but by several couples of memory area. Let's suppose there are two couples of memory areas, one couple (S1-S2) is very small compared to the other one (L1-L2), the allocation are always made in the small area which 'turn' very quickly, when a GC occurs the still reached memory blocks whose resist still the previous GC goes in the large memory area. So the blocks having a short life don't go in the large area, and because the small are is small the GC is fast. An other advantage is that the large area is managed incrementally during the execution, the goal is to not top brutaly the execution. The implementation of this GC is very complicated, it was used with success for MAIA, but to work the GC must be taken into account in many levels, even in the OS. - the counters : each allocated block has a counter of reference, when the counter become 0 the block is free for a re-use. Like for the mark & sweep the blocks are never moved, so some hole appears, furthermore some objects are never free, for instance when you have a circle each element is still referenced even the circle itself is not referenced. The advantage of this GC is that the execution is never stopped (... except if you add an other GC to manage circle), but you must update the counter of references each time an address is saved 'somewhere'. I don't know which GC is used by Java, I just can see that during the GC the execution is stopped. More that the cost of the GC itself, the disavantage is that when a GC is present all the allocations are made in the heap, and an allocation / desallocation in the heap is expensive. In C++ temporary allocations may be made in the stack, in this case and the 'allocation / de allocation' cost is nothing, it is enough to update the stack pointer :-) To have or not a GC can't be considered out of any external reasons, all depend on the usage of the language. For instance to have a GC in Java and to pay for that is not a problem in many cases where the respons time is not a problem, and where you don't want to 'loose' implementation time to save the memory, for instance to execute a small program attached to a web feature. The problem is not the GC in Java, the problem is to use Java in the cases it is not adapted and for instance where C++ is a better choice ... Each language has its advantages, but the more the language is specific, the less its field of application is large. Bruno Bruno -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Francis Glassborow Guest Posted: Thu Dec 28, 2006 2:48 am    Post subject: Re: Garbage Collection - The Trash Begins To Pile Up In article <Df-dndbRhfBH7w_YnZ2dnUVZ8qeknZ2d (AT) pipex (DOT) net>, Stephen Howe <sjhoweATdialDOTpipexDOTcom (AT) giganews (DOT) com> writes Quote: But I regard it as alarmist, the addition of GC to C++ will _never_ happen except as an optional component which was Bjarne's original vision (and to date in tihs newsgroup, I have never seen a GC aficionado talk about the optionality of GC for C++ which leads me to believe they regard it as compulsory). I have never seen one write as if he thought it should be compulsory. I have several time posted asserting the optional nature and I have never had anyone post to rebut that as being insufficient for their needs. I am pretty certain that none of them regard it as compulsory other than that it should be required that implementations support GC (not that does not mean anyone has to use it :) -- Francis Glassborow ACCU Author of 'You Can Do It!' and "You Can Program in C++" see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/youcandoit/projects [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Francis Glassborow Guest Posted: Thu Dec 28, 2006 2:49 am    Post subject: Re: Garbage Collection - The Trash Begins To Pile Up In article <1167208673.973198.27750 (AT) h40g2000cwb (DOT) googlegroups.com>, Le Chaud Lapin <jaibuduvin (AT) gmail (DOT) com> writes Quote: "Deep ramifications." That's strange. I thought the purpose of GC was to relieve the programmer of thinking about deep ramifications. But GC is about memory management which is a subset of destructors that are about resource management. There are many places in modern program design where we would love to avoid having to worry about memory management and GC does that for us. Unfortunately in many languages that rely on GC, the result is that the programmer has to explicitly manage all other resources and so be aware of the lifetimes of all objects that use dynamic resources (other than memory). Those resources are often far scarcer than memory yet few objects rely on them The consequence is that programmers are more likely to mismanage them (things that rarely matter are much harder to learn) Our problem in C++ is to couple GC and dtors to provide an optimal mix, memory is managed implicitly and other dynamic resources are managed by dtors. The problem is not for the programmer but for the language design. If we can get it right we have a win-win situation (and those who do not want to use GC, need not do so.) The intent is NOT to force everyone to use GC, but to ensure that those using it can still rely on dtors for other resource management. We very definitely do not want to loose the latter capability in providing the former. I get pretty irritated by people who continually oppose something on the grounds that they have no use for it. By all means oppose something if the consequence is detrimental to something you do use. Yes there are issues of overall complexity and the Standards committees are pretty sensitive to those. However GC has always been considered as an optional tool in C++ (certainly Bjarne Stroustrup has never been against it as such, only against making its use compulsory) -- Francis Glassborow ACCU Author of 'You Can Do It!' and "You Can Program in C++" see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/youcandoit/projects [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Greg Herlihy Guest Posted: Thu Dec 28, 2006 2:57 am    Post subject: Re: Garbage Collection - The Trash Begins To Pile Up Le Chaud Lapin wrote: Quote: Yet, when a programmer uses the GC model, they might experience the following problems: * An OutOfMemoryException is thrown. * The process is using too much memory for no obvious reason that you can determine. * It appears that garbage collection is not cleaning up objects fast enough. * The managed heap is overly fragmented. * The application is excessively using the CPU. All of these symptoms make me wary, but the second (*) is most impressive... "for no obvious reason that you can determine". The last word in this sentence, "determine", is closely related to another word, "determinism", a feature of C++ that is probably the basis for having never experienced any of these problems in C++. In comparison, the typical memory problems of a C++ program are far more serious: memory leaks, heap corruption, memory "stomping", invalid output, "crashes" far removed from the site of the error - the variety of potential C++ memory-management errors is practically infinite, and uniformly disasterous. Unless C++ is intended to become a programming language exclusively for hobbyists and others who write programs for their own enjoyment - then the C++ language has to evolve from its 80s-era origins if it is to remain economically competitive as a programming language today. Fortunately, the C++ committee can read the writing on the wall as well as anyone: manual memory management is far too error-prone, produces programs that are far too expensive to debug and maintain, and even fails to deliver on the type safety guarantees of the language itself, to be presented as a serious alternative to automated memory management. C++ without any form of automated memory management cannot be taken seriously as a commercial-grade computer programming language today, and even less so, tomorrow. Greg -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Le Chaud Lapin Guest Posted: Thu Dec 28, 2006 10:10 am    Post subject: Re: Garbage Collection - The Trash Begins To Pile Up Greg Herlihy wrote: Quote: In comparison, the typical memory problems of a C++ program are far more serious: memory leaks, heap corruption, memory "stomping", invalid output, "crashes" far removed from the site of the error - the variety of potential C++ memory-management errors is practically infinite, and uniformly disasterous. This viewpoint is very old in engineering and simply wrong. I've had computer science students complain that electrical engineering would be more fun if the math were not so complicated. The problems you listed are caused by programmers doing things they should not be doing. The degree to which such problems manifest is directly proportional to the degree to which programmers persists in doing things that they should not be doing. Quote: Unless C++ is intended to become a programming language exclusively for hobbyists and others who write programs for their own enjoyment - then the C++ language has to evolve from its 80s-era origins if it is to remain economically competitive as a programming language today. The only group I see clearly benefiting from the "evolution" of C++ is a large software company in the northeastern United States. The mess caused by introducing GC into C++ would directly and indirectly result in huge revenue increases for that company. In fact, it is to that company's benefit to not have C++ be portable. If it is non-portable, causes many issues, requires more design "tools", etc, that is all activity. And activity in the software space translates to revenue for any company that supports that activity, whether it is Perrier, International Paper, Bic, Air Bus, Hilton Hotels, 3M, Sharpee, XYZ GC Optimization Tools, Inc., whatever. There is a Belgian expression that accurately characterizes what is going on with the new trend in "sloppy kill-the-type-system mix-and-match coding style" that is going on today. Unfortunately, its vulgarity prevents me from writing it int his post, but essentially, it says that, when you are done doing what you were doing, nothing is really accomplished, but everyone feels like it has. I've spend more time in the past 6 months help people with GC issues in languages that I don' t even know than I have spent on related memory issues in my entire lifetime of C and C++. If I were to add up the money wasted in salary for those people doing ..whatever it is they are doing...it is simply huge. Quote: Fortunately, the C++ committee can read the writing on the wall as well as anyone: manual memory management is far too error-prone, produces programs that are far too expensive to debug and maintain, and even fails to deliver on the type safety guarantees of the language itself, to be presented as a serious alternative to automated memory management. Failure of programmer or failure of language. I say failure of programmer. Quote: C++ without any form of automated memory management cannot be taken seriously as a commercial-grade computer programming language today, and even less so, tomorrow. I might start believe this statement when GC proponents start writing their GC's in a language other than C++. -Le Chaud Lapin- -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Nemanja Trifunovic Guest Posted: Thu Dec 28, 2006 10:10 am    Post subject: Re: Garbage Collection - The Trash Begins To Pile Up Le Chaud Lapin wrote: Quote: The purpose of this post is to provide a bit of empirical evidence that GC is no panacea, and that adding it to C++ might do more harm than good. I agree with most of the points from your post, but there is nothing to worry about: C++ is not and will *never* be a garbage-collected language. It is possible that we see optional garbage collection added to the language, but I doubt even that will happen. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Le Chaud Lapin Guest Posted: Thu Dec 28, 2006 10:10 am    Post subject: Re: Garbage Collection - The Trash Begins To Pile Up Francis Glassborow wrote: Quote: I am pretty certain that none of them regard it as compulsory other than that it should be required that implementations support GC (not that does not mean anyone has to use it But Francis, Don't you think that this will cause a lot of confusion about how to best handle memory management? What about the the reputation of the language? If GC is added to the language proper: 1. Advanced C++ programmers who never wanted GC in C++ will already know to abstain from using it as the general mechanism for memory management. 2. Advanced C++ programmers who wanted GC in C++...I have no idea what they would do... but I suspect that a significant number of them will use it as the general mechanism for memory management for x% of the time, where x is a number > 1 and < 100. Because we are all human, dx/dt will likely be > 0. 3. Novice C++ users will likely lack the experience to properly judge, and being an educator, certainly you would agree that beginners often choose the path that they perceive to be that of least resistance. That's why GC is so popular in C# and Java - there is the common misconception that it relieves them from having to think about memory management. The same happens in other disciplines. But the vast majority of programmers do not program in isolation. Code is written, shared, maintained, passed along, prescribed, etc. Eventually, novice become experts, if not by skill, then by title. Then you end up with a situation where people who were once novices are prescribing designs that are inherently flawed because of the erroneous perception that memory does not have to be managed. Their lack of forethought in the design adversely affects the quality of the code. The poor code quality leads to instability, unreliability, and significant problems with maintainability. And this ultimately affects the reputation of C++. In the technical press, no one will write, "Engineers not appreciating the fundamental principle of good form falsely assumed that GC was a silver bullet and repeatedly concocted designs that were inherently defective, unwieldy, unstable, and unreliable using a language that readily supports good form, stability, and reliability: C++." Instead they will write, "C++ has serious memory management issues." After that, we anti-CG programmers could quickly find ourselves in a situation defending C++ against managerial revocation due to a degradation in integrity that was, ironically, induced by people who never understood the spirit of the language in the first place. This is a real possibility - just recently, the boss of a friend of mine in a software company declared that there would be a complete rewrite of all the code - in C#. The problem was COM ...someone got the idea 10 years earlier that COM was the solution to all things grand - and it turned out that it was not, and the (wishfully-thinking) programmers made a horrific mess out of the code base, but C++ got a bad reputation for it. Now my friend could try to say to his boss - "Wait...the problem wasn't C++...the problem was that you used C++ in a manner that counter to its proper usage."..but that won't matter. What is done is done. C++ is out. C# is in. So I would rethink the notion that adding GC to the language is harmless because the use of it is optional. If that were the case, then we might as well add support for inline Lisp and many other things that an equal number of people would consider useful. -Le Chaud Lapin- -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Joe Seigh Guest Posted: Fri Dec 29, 2006 1:53 am    Post subject: Re: Garbage Collection - The Trash Begins To Pile Up Greg Herlihy wrote: Quote: In comparison, the typical memory problems of a C++ program are far more serious: memory leaks, heap corruption, memory "stomping", invalid output, "crashes" far removed from the site of the error - the variety of potential C++ memory-management errors is practically infinite, and uniformly disasterous. Unless C++ is intended to become a programming language exclusively for hobbyists and others who write programs for their own enjoyment - then the C++ language has to evolve from its 80s-era origins if it is to remain economically competitive as a programming language today. Fortunately, the C++ committee can read the writing on the wall as well as anyone: manual memory management is far too error-prone, produces programs that are far too expensive to debug and maintain, and even fails to deliver on the type safety guarantees of the language itself, to be presented as a serious alternative to automated memory management. The arguments for garbage collection are a bit contrived and overblown. There is no silver bullet. GC isn't going to make bad programmers into good programmers. In some instances it can make things worse by turning detectable errors into silent errors. If you think debugging a crash that occurred much later than the actual error is difficult, try debugging a bug caused by a silent error which will leave no clues at all as to where the error occurred. I've debugged multi-threaded crash dumps including ones where not finding the bug was not an option, where you were not allowed to tell an enterprise customer that the bug "could not be reproduced", a cop out which unfortunately way too may software vendors use today. The hardest ones were the silent bugs without crash dumps. Dumps where data is overwritten by other data? Hey, that's a clue and much better than no clue at all. Unless you're one of those software vendors who thinks that customers not being able to prove that a bug exists is a good thing. The actual value of GC, some implementations of it anyway, is as a form of PDR for sharing data between threads. There are a number of problems here. One is that you cannot pretend multi-threading does not exist for the purpose of your base language definitions and then add multi-threading on top of that and then expect that no problems will be caused by that. Another problem is pretending that GC is totally distinct from smart pointers, another form of PDR. So you end up with two solutions to the same problem with different and inconsistent approaches taken w.r.t. the C++ language. And some of the approaches may preclude alternatives. E.g., GC might become optional but you might not be allowed to use alternate implementations of GC. That can happen in part because pointer in a GC may look like regular pointers, they aren't. In order for non conservative GC to work, it has to know where the pointers are. Which means support by the compiler for only certain implementations of GC. E.g. they only support pointers that are equivalent to void* and can be dereferenced directly. Abstract pointer support that would support any form of GC or smart pointer would be nice and would avoid this sort of problem but I don't think that's going to happen. -- Joe Seigh When you get lemons, you make lemonade. When you get hardware, you make software. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Le Chaud Lapin Guest Posted: Fri Dec 29, 2006 10:10 am    Post subject: Re: Garbage Collection - The Trash Begins To Pile Up Stephen Howe wrote: Quote: Your post is interesting, particularly the articles of what happening in the ..NET world concerning memory management and RC. And I agree with you on the damage of adding GC to C++. But I regard it as alarmist, the addition of GC to C++ will _never_ happen except as an optional component which was Bjarne's original vision (and to date in tihs newsgroup, I have never seen a GC aficionado talk about the optionality of GC for C++ which leads me to believe they regard it as compulsory). Optional I can live with. At this point it becomes political in whether the "option" is purely by the programmer as well as the vendor. Optional all the way around seems reasonable. GC, in the form of a library / framework that does not fundamentally change the language, might be the best option. That way, if it turns out that the GC people were wrong, at least the language would not have been irrevocably altered. -Le Chaud Lapin- -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ion Gaztañaga Guest Posted: Fri Dec 29, 2006 10:10 am    Post subject: Re: Garbage Collection - The Trash Begins To Pile Up Quote: I have snipped the rest because they are largely FUD. I know that current education as regards programming has a lot to be desired but refusing ot provide support for GC will not help. Most of the next generation of students will have been used to using a GC supporting language. I see a certain analogy to pointers, except this time in reverse. C++ has pointers but there use is largely optional (I can and do write large amounts of code without ever using an explicit pointer) However pointers are in the language for two reasons: support of legacy code from C, support for low-level programming. Raw pointers should, IMO, be learnt later rather than earlier and used only when the task needs them (and pointer arithmetic would be rare outside low-level classes) I was thinking about writing about this in comp.std.c++ this week, but I can't resist joining this thread. The problem with "optional" is that "optional" can mean many things. I find current proposal (N2128) very discouraging. It proposes overloading "new" and "delete" so everyone must design its generic designs to both garbage and non-garbage collection environments (I must call delete always). On the other hand, I can't count with deterministic resource liberation (something I suppose also in STL containers) because my code can be used with garbage collection. Really disturbing. If a library returns a pointer, I don't know if its garbage collected or I must free it. The type of the pointer is the same for GC memory or manual memory allocation. Apart from that I must start tagging all my classes with gc forbidden/gc strict, to avoid more than necessary garbage search from the collector. In my opinion, it's not true that we have several years of experience on GC with C++. We have some libraries (Boehm GC, for example) that makes our whole program garbage collected. The only widely used language mixing GC and manual memory is Managed C++. And they chose to use different pointer types and allocation functions to separate both worlds. My opinion is that GC should be treated as a new smart pointer, so that at compile time, I know if I should free that pointer or not (gc_pointer). With such pointer and a new allocation function "gc_new" I know that gc_pointer is much like shared_ptr with no deterministic finalization. Making raw pointers and new/delete garbage collected plus tagging all standard classes is in my opinion, a bad idea with no previous experience, because changes the semantics of my precompiled library (that it's counting on C++ deterministic features) when linking it with a garbage collected environment. And I don't want to start tagging my classes as gc_forbidden to avoid this. Supporting raw pointers can also limit the GC algorithms that can be used (can we use non-conservative, compacting, algorithmthms?). Quote: From the proposal: "Unlike the C++/CLI approach, transparent garbage collection allows easy \cut-and-paste" reuse of existing source code and object libraries without the need to modify their memory management or learn how to manipulate two types of pointers." I don't thing code migration should be the reason for that. Old c++ code is written for manual management. If that code has memory leaks, let's fix them. For most data, we know its lifetime. For the rest, let's have gc_pointer/gc_new. Just my 2 cents. I was quite reluctant to GC some months ago (after all, I almost never write "new[]" expressions, because I use STL containers, RAII, and the stack) but after N2128, I'm really worried. Regards, Ion -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Carlos Moreno Guest Posted: Fri Dec 29, 2006 10:10 am    Post subject: Re: Garbage Collection - The Trash Begins To Pile Up Sean Kelly wrote: Quote: 3. Novice C++ users will likely lack the experience to properly judge, and being an educator, certainly you would agree that beginners often choose the path that they perceive to be that of least resistance. That's why GC is so popular in C# and Java - there is the common misconception that it relieves them from having to think about memory management. The same happens in other disciplines. This would require the novice programmer to be somewhat familiar with the C++ standard library [...] And in my experience, many novice programmers simply aren't that familiar with the C++ standard library. Not beyond perhaps std::string and iostreams at any rate. And vector, I bet. But then, why would a beginner C++ programmer need anything beyond string, vector, and streams? That *is*, IMHO, the right way to go about starting with C++; not pointers and all the madness now supported by the fact that the beginners need not worry about anything because there's "daddy-GC" that will be there to clean up after us, no matter what attrocities we may have done. (that is, hypothetically speaking) Carlos -- -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Nemanja Trifunovic Guest Posted: Fri Dec 29, 2006 10:10 am    Post subject: Re: Garbage Collection - The Trash Begins To Pile Up Francis Glassborow wrote: Quote: In article <1167258570.556475.222910 (AT) 79g2000cws (DOT) googlegroups.com>, Nemanja Trifunovic <ntrifunovic (AT) hotmail (DOT) com> writes Le Chaud Lapin wrote: The purpose of this post is to provide a bit of empirical evidence that GC is no panacea, and that adding it to C++ might do more harm than good. I agree with most of the points from your post, but there is nothing to worry about: C++ is not and will *never* be a garbage-collected language. It is possible that we see optional garbage collection added to the language, but I doubt even that will happen. I would lay heavy odds that you are mistaken. Mandatory optional GC (i.e. compilers are required to provide it if the programmer wants it) is almost certain to be part of any multi-threading option and if the next version of C++ does not have explicit support for efficient multi-threading on multi-core processors it will be a dying language. So you are saying efficient multithreading is not possible without GC? -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Goto page 1, 2, 3 ... 10, 11, 12  Next Page 1 of 12   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.