On Sun, Nov 18, 2012 at 06:37:29PM +0000, Jonathan Wakely wrote: > On 18 November 2012 18:25, Basile Starynkevitch wrote: > > On Sun, Nov 18, 2012 at 08:06:08AM -1000, NightStrike wrote: > >> On Sun, Nov 18, 2012 at 8:03 AM, Basile Starynkevitch > >> <bas...@starynkevitch.net> wrote: > >> > I really think that GCC need some form of garbage collector. > > [...] > >> > >> What's wrong with std::shared_ptr? > > How does it deal with complex circular references that every compiler has? > > > > I'm understanding that std::shared_ptr cannot realiably deal with circular > > references > > (because it maintains essentially a reference counter). > > > > Could you explain me how std::shared_ptr deal with circular references? > > See http://gcc.gnu.org/ml/gcc/2011-10/msg00285.html
Which mentions weak_ptr, which sort of prove my point. You are suggesting that by appropriately and wisely mixing shared_ptr & weak_ptr, some circular references could carefully be handled (with caution and care). I'm thinking that using them reliably in GCC (a so big piece of software that very few people understand it enough) is practically impossible for newbies, because it requires them to understand very deeply all the possible interactions between other pieces of software and their own. I do know about shared_ptr & weak_ptr (20+ years ago, I developped a lot of NeWS code -NeWS was a graphical window server then developped at Sun and it has also weak & shared references inside their PostScript superset). By experience, these notions do not scale well to huge software base like GCC. So my thinking is that, to lower the [huge] difficulties of enabling GCC newbies to contribute robust code to GCC, a systematic approach like the one given by gengtype+ggc, or the one possible with a real garbage collector, you don't put the burden of knowing exactly where to put shared_ptr, where to put auto_ptr, where to put weak_ptr, onto the shoulders of GCC newbies. A garbage collector provides a systematic, fail-proof, solutions (of course, even with a GC, memory leaks can happen; but they are much less dangerous than sigsegv). And notice also that the current GCC internal representations have very incomplete documentation. (most of the good documentation is outside GCC, e.g. on http://www.cse.iitb.ac.in/grc/gcc-workshop-12/ etc). There is nowhere on gcc.gnu.org a clear picture (or a clear, but complete text) of all the major GCC internal representations (gimple, gimple_seq, basic_block, edge, loop, cgraph, ...) and all their interdependencies. I believe that GCC needs to worry much more about attracting and keeping new young talents, and systematic solutions (like the one provided by a garbage collector) are much more appropriate than shared_ptr+weak_ptr tricks. I am in favor of more generic and easy solutions, than ones which require a deep knowledge of an huge existing undocumented or under-documented code base (even if such approaches would slow down the compilation time a little bit; so I would accept the 5% slowdown possible with Boehm GC). I notice (and I am not alone) that most young people attracted by working on compilation of procedural languages are today lurking on LLVM, not on GCC. Using std::shared_ptr & std::weak_ptr reliably is not realistic for newbies on a such large (and such under-documented) legacy code base as GCC. Gengtype+ggc is ugly, but it did provide a systematic way to add data inside GCC. shared_ptr+weak_ptr don't provide a systematic way. Regards. PS. LLVM has also a decisive documentation advantage w.r.t. GCC -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mines, sont seulement les miennes} ***
