From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68220 invoked by alias); 14 Jan 2019 15:39:18 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 68209 invoked by uid 89); 14 Jan 2019 15:39:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=plural, interest X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 14 Jan 2019 15:39:16 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C955480F7B; Mon, 14 Jan 2019 15:39:14 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id EE6885DEB4; Mon, 14 Jan 2019 15:39:13 +0000 (UTC) Subject: Re: [PATCH 00/12] remove some cleanups using a cleanup function To: Andrew Burgess , Tom Tromey References: <20190109033426.16062-1-tom@tromey.com> <87fttxx45t.fsf@tromey.com> <878szpv6qg.fsf@tromey.com> <20190114110601.GL3456@embecosm.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <52c08949-2dba-f1e8-5ddf-b4174fe21283@redhat.com> Date: Mon, 14 Jan 2019 15:39:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20190114110601.GL3456@embecosm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-01/txt/msg00328.txt.bz2 On 01/14/2019 11:06 AM, Andrew Burgess wrote: > * Tom Tromey [2019-01-12 15:41:43 -0700]: > >> Andrew> How do you think this compares to your original patches? Any interest >> Andrew> in this approach? >> >> Tom> Yes, let's do this. >> >> I happened to stumble across the message for commit >> 9bcb1f1630b05594fa86bfd017639cfcc966b11c today. It references >> >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4189.pdf >> >> ... which proposes a generic scope guard class along these lines. >> So, now I wonder if we should just reuse that paper's contents, but in >> the gdb namespace. Ah, I was just about to point at that paper, and at Alexandrescu's ScopeGuard/SCOPE_EXIT. > > Interesting, there's a revised version here: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0052r5.pdf > > Which includes details about how the technique can be expanded to > effectively give us `cleanup_on_failure` and/or `cleanup_on_success`, > which would allow us to completely remove the use of the current > `.reset ()` or `.cancel ()` functions. IIRC, to implement that correctly we'd need std::uncaught_exceptions() [plural, C++17], the older std::uncaught_exception() [singular] is flawed. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4152.pdf . Thanks, Pedro Alves