From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8300 invoked by alias); 19 Oct 2011 16:54:10 -0000 Received: (qmail 8286 invoked by uid 22791); 19 Oct 2011 16:54:09 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 19 Oct 2011 16:53:55 +0000 Received: by wwe32 with SMTP id 32so1694287wwe.8 for ; Wed, 19 Oct 2011 09:53:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.221.163 with SMTP id r35mr2878694wep.21.1319043233784; Wed, 19 Oct 2011 09:53:53 -0700 (PDT) Received: by 10.216.36.78 with HTTP; Wed, 19 Oct 2011 09:53:53 -0700 (PDT) In-Reply-To: <4E9E7F6F.8050601@free.fr> References: <20111018171201.361304028ab94f102f827bd2@starynkevitch.net> <20111018191350.470cd6b1cd291373d5ff3f2c@starynkevitch.net> <20111019080021.4e1acb3687fc8ceacc2fd7a3@starynkevitch.net> <20111019082210.3834624fc4dc8734fd6337c6@starynkevitch.net> <4E9E7F6F.8050601@free.fr> Date: Wed, 19 Oct 2011 22:19:00 -0000 Message-ID: Subject: Re: adding destroyable objects into Ggc From: Jonathan Wakely To: Duncan Sands Cc: gcc@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg00325.txt.bz2 On 19 October 2011 08:42, Duncan Sands wrote: > Hi Gabriel, > >>> I also agree with you that GCC architecture is messy, and that scares >>> newscomer a lot. >>> >> >> Yes, but the way we improve it isn't, in my opinion, adding more GC. >> First we would like to remove complexity, and I do not think we should >> start by focusing on storage management until we get a clearer idea >> about lifetime of data structures we manipulate and how they mesh. >> We might find out (as I suspect) that the builtin GC of C (or C++) is >> remarkable at the job, provided we have a design that makes the >> lifetime obvious and take advantage of it. > > what you say sounds very sensible to me. =A0If you look at LLVM, most mem= ory > management is done by using container objects (vectors, maps etc) that > automatically free memory when they go out of scope. =A0This takes care > of 99% of memory management in a clean and simple way, which is a great > situation to be in. And LLVM seems to be very popular with newcomers to the code base. My impression is that noone working with the code is intimidated by properly-managed object lifetimes and the lack of garbage collection.