From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9294 invoked by alias); 20 Oct 2011 14:52:44 -0000 Received: (qmail 9272 invoked by uid 22791); 20 Oct 2011 14:52:42 -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; Thu, 20 Oct 2011 14:52:27 +0000 Received: by wwe32 with SMTP id 32so3050229wwe.8 for ; Thu, 20 Oct 2011 07:52:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.15.14 with SMTP id e14mr8908321wee.21.1319122345584; Thu, 20 Oct 2011 07:52:25 -0700 (PDT) Received: by 10.216.36.78 with HTTP; Thu, 20 Oct 2011 07:52:25 -0700 (PDT) In-Reply-To: <20111020115652.GA14705@ours.starynkevitch.net> References: <20111018171201.361304028ab94f102f827bd2@starynkevitch.net> <20111018191350.470cd6b1cd291373d5ff3f2c@starynkevitch.net> <20111019135602.GA19325@ours.starynkevitch.net> <20111020115652.GA14705@ours.starynkevitch.net> Date: Thu, 20 Oct 2011 15:14:00 -0000 Message-ID: Subject: Re: adding destroyable objects into Ggc From: Jonathan Wakely To: Basile Starynkevitch Cc: Laurynas Biveinis , gcc@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 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/msg00355.txt.bz2 On 20 October 2011 12:56, Basile Starynkevitch wrote: > > (amongst those advocating C++ smart or whatever _ptr-s) Please stop saying "smart or whatever _ptr-s" - the term "smart pointer" has a commonly accepted meaning and is well understood. It's a generic term, it doesn't refer to a particular smart_ptr class. Your repeated use of that phrasing is as silly as referring to MELT as a "gcc plug or whatever in" > explained how he believes the current GCC GTY-ed representations (like tree, > gimple, gimple_seq, edge, loop-s...) could be re-implemented in C++ using > C++ tricks without Ggc, and what could be the transition from the current > state of GCC to such a future state (C++--full, but Ggc-less) of GCC. The fact noone has done it yet, or explained it in detail, doesn't mean it can't happen. > I might be grossly wrong, but nobody explained -with concrete examples- us > how the current major GCC representations could be done inside GCC with C++ > but without Ggc. For instance, nobody explained what an hypothetical class > Gimple or class Gimple_Seq could be. Well you haven't showed concrete examples of your C++-friendly Ggc either (your suggested code wasn't valid C++). Does that mean we should be sceptical and doubt your suggestion is possible? Why assume that the current major GCC representation have to remain the same? Maybe they will need to be modified.