On Tue, Oct 18, 2011 at 10:41 AM, Basile Starynkevitch <bas...@starynkevitch.net> wrote: > On Tue, 18 Oct 2011 10:36:08 -0700 > Ian Lance Taylor <i...@google.com> wrote: > >> On Tue, Oct 18, 2011 at 10:13 AM, Basile Starynkevitch >> <bas...@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
