On 19 November 2012 19:35, Basile Starynkevitch wrote: > 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.
Of course it mentions weak_ptr, that's the way shared_ptr is designed to deal with cycles. > 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. No it doesn't. > I do know about shared_ptr & weak_ptr Then why did you ask how shared_ptr deals with circular references? > 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, As I said in http://gcc.gnu.org/ml/gcc/2011-10/msg00285.html noone except you has mentioned auto_ptr, stop attacking that strawman. > 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). Why would you get a sigsegv using shared_ptr and weak_ptr? This is another strawman. > 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. Please stop referring to anything you don't like/understand as "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. Which doesn't use tricks like GC, as has been pointed out to you repeatedly. > 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. Simply claiming it repeatedly doesn't make it true.
