adding destroyable objects into Ggc

[Basile Starynkevitch]

On Wed, 19 Oct 2011 00:45:58 -0500
Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> 
> There is no reason to assume or to believe that people who argue for
> less GC aren't familiar with GC --  a regrettably  not so uncommon
> jugemental mistake.

However, I don't often see the people arguing against Ggc talking about the difficulties
for GCC newscomers to dive inside GCC and be able to propose code. In particular, I did
not understand any coding rules or guidelines, or even hypothetical examples, which, when
GCC becomes manually memory managed (and the smart or whatever _ptr-s offered by C++
fall into this), will help them to avoid memory leaks.

(and while I agree Ggc is somehow weak, I'm in the minority who believes a garbage
collector is needed, and Ggc should be improved or replaced by a better garbage collector,
not removed; my GC belief is mostly motivated to help new GCC developers, and because of
GCC enormous size).

Even more, I saw no patches submitted to trunk to remove Ggc, and I saw no patches
submitted to trunk to "improve" core Gcc internal representations (tree-s, gimple-s,
gimple_seq-s, edge-s ...) by using C++ language constructs. It even has never been
discussed in details. I sincerely have absolutely no idea how smart or whatever kind of
_ptr-s in C++ will permit moving gimple-s or tree-s outside of Ggc (to the point that I
believe it is not realistically achievable). I'll be delighted to get explanations &
"proof-of-concept" style code samples.

Cheers.

-- 
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 mine, sont seulement les miennes} ***