From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116791 invoked by alias); 30 Oct 2017 09:32:10 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 116765 invoked by uid 89); 30 Oct 2017 09:32:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=love X-HELO: mail-wm0-f41.google.com Received: from mail-wm0-f41.google.com (HELO mail-wm0-f41.google.com) (74.125.82.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 30 Oct 2017 09:32:08 +0000 Received: by mail-wm0-f41.google.com with SMTP id r68so14988670wmr.3 for ; Mon, 30 Oct 2017 02:32:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=NF2wOx2dh6pvtbkTYJ91kczikDTH7hrxwU5aW5Whrw4=; b=MfcGyEEZDbHwer/FGXpO4JrJC2whNvA98g93jEr+iq+KYXu5q2ml8JTbL7p/VqdNww MFWdgO1LQ30xB4wXdwWjgefhaLftl4P6jqprGOD/XPgyVAu7n81ASU84dsPvGBjvDoIY 4J3ybnQI6WlfpHzV8q6uQ9hf4vNPrK8xr7hF8ZP/CEuic5CjyNXBSWLeKyfCoCXhRqDp GNlMrswwnem4u8P94Cx43qgCsmASRZ9ayEc16y3lmLPlOT6MhjD6s2DEs94YkFBZ6qym ylSBwmsPt18i0kMf8weOT+ZuYOyggKyIC1EvwLSoLPPj8qgOUrhJ0szWc10/bLFD4xP9 0NKQ== X-Gm-Message-State: AMCzsaUc6aDu8SkcCFKpe5sNwMmIKrg21N+dDb5RU1+ZcOdBkv9FVUh5 V5XggwGaAD5sxcQrxsubRYj8ng== X-Google-Smtp-Source: ABhQp+TezwDASrKXWMN9hSP6aDft+44j2TIhjN8ZZxJ+ua+YiXoStzj1yjwkydmyn+lYYt/IkLSd7A== X-Received: by 10.80.244.2 with SMTP id r2mr11066199edm.26.1509355926315; Mon, 30 Oct 2017 02:32:06 -0700 (PDT) Received: from [192.168.0.101] (bl17-148-124.dsl.telepac.pt. [188.82.148.124]) by smtp.gmail.com with ESMTPSA id f46sm10104480edd.80.2017.10.30.02.32.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Oct 2017 02:32:05 -0700 (PDT) Subject: Re: [RFA][PATCH] Provide a class interface into substitute_and_fold. To: Jeff Law , David Malcolm , gcc-patches References: <1508878644.17132.30.camel@redhat.com> <6751dcfb-4d19-b857-1848-769bfadfcbc2@redhat.com> From: Pedro Alves Message-ID: <75fcb29f-bc76-ac34-e0ad-6738ff66f532@palves.net> Date: Mon, 30 Oct 2017 10:07:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <6751dcfb-4d19-b857-1848-769bfadfcbc2@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-10/txt/msg02168.txt.bz2 On 10/25/2017 06:20 PM, Jeff Law wrote: > My conclusion on the virtual dtor issue is that it's not strictly needed > right now. > > IIUC the issue is you could do something like > > base *foo = new derived (); > [ ... ] > delete foo; > > If the base's destructor is not virtual and foo is a base * pointing to > a derived object then the deletion invokes undefined behavior. > > In theory we shouldn't be doing such things :-) In fact, if there's a > way to prevent this with some magic on the base class I'd love to know > about it. There is: make the base class destructor protected. Thanks, Pedro Alves