Re: adding destroyable objects into Ggc

[Ian Lance Taylor <iant@google.com>]

On Tue, Oct 18, 2011 at 10:41 AM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
> On Tue, 18 Oct 2011 10:36:08 -0700
> Ian Lance Taylor <iant@google.com> wrote:
>
>> On Tue, Oct 18, 2011 at 10:13 AM, Basile Starynkevitch
>> <basile@starynkevitch.net> wrote:
>> >
>> > Still, I find strange that while some very smart & nice GCC guys want to get rid of Ggc,
>> > no patch made into the trunk towards that goal (which I Basile dislike and don't share,
>> > so don't expect me Basile to work on this.).
>>
>> I've put a lot of work into making it possible to build gcc as a C++ program.
>
> I do know that, and as many GCC developers I am grateful to you Ian for your big work.
>
> However, I don't know very well auto_ptr.  Could you explain to use how do they deal with
> *circular* memory references.... (perhaps by taking as examples code inside GCC).
> My feeling is that auto_ptr is not able to deal with them, but I'll be delighted to be
> proven wrong.

auto_ptr is confusing and hard to use.  Don't think about it.

I think a better approach here is likely to be a reference counted
shared_ptr for the
most general case.  It's true that it works poorly with cycles, but
gcc data structures
are only occasionally cyclical.

Also, I think that actually many cases in gcc do not require
shared_ptr.  Instead, we
can think of terms of pools, with the smart pointers being aware of
which pool they are
associated with.  Then we can detect at compile time an accidental use
of a pointer to
one pool being assigned to a pointer to a different pool.  Before we
introduced garbage
collection, gcc used pools (well, obstacks), but there were severe
problems because
pointers to one pool would be assigned to a pointer to a different
pool and then become
dangling pointers when the first pool was deleted.  C++ will let us
avoid that problem.

Ian