From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86432 invoked by alias); 13 Oct 2016 15:43:42 -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 86392 invoked by uid 89); 13 Oct 2016 15:43:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=6a, Hx-languages-length:2060 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; Thu, 13 Oct 2016 15:43:30 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3889880086; Thu, 13 Oct 2016 15:43:29 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9DFhQLJ013855; Thu, 13 Oct 2016 11:43:26 -0400 Subject: Re: [RFA 09/22] Remove make_cleanup_restore_current_ui To: Eli Zaretskii References: <1474949330-4307-1-git-send-email-tom@tromey.com> <1474949330-4307-10-git-send-email-tom@tromey.com> <2f79a489b9090701f15fc04e0017c236@simark.ca> <87y41xd0dt.fsf@tromey.com> <1f5898b8-6be9-48e6-4312-72ec90e7810e@redhat.com> <87insxmbnd.fsf@tromey.com> <2855e2ec-46dc-71b7-9943-8edaebcbef90@redhat.com> <8337k0aicw.fsf@gnu.org> <6f27db2e-4b88-b72a-5836-080c3583eb7f@redhat.com> <83r37k8ifg.fsf@gnu.org> <83lgxs8fyj.fsf@gnu.org> <9d9dca17-56a6-6c0a-44bb-efc425f24d8d@redhat.com> <83k2dc8ef4.fsf@gnu.org> Cc: tom@tromey.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org From: Pedro Alves Message-ID: <685ed94c-fd1b-6b0a-4fe0-0418966b184f@redhat.com> Date: Thu, 13 Oct 2016 15:43:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <83k2dc8ef4.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00381.txt.bz2 On 10/13/2016 04:19 PM, Eli Zaretskii wrote: >> Cc: tom@tromey.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org >> All I know right now that we sorely need an owning smart pointer. >> And for this particular case, I think it makes a ton of sense to go >> dual dialect. > > But if we agree to require C++11 starting from now, you can go ahead > with your patch, and don't even need the other dialect. So this > sounds like a win-win solution to me. Well, that'd be perfect. But as I mentioned elsewhere, I'd prefer to take a staged approach to C++11. I.e., have a fallback plan. My shim would actually _help_ with that. So the plan would span a few weeks, and it'd be: #1 - get gdb::unique_ptr in #2 - start using unique_ptr throughout (there's a ton of work to do here, and it go on in parallel with the remainder of the plan.) #3 - install the patch that switches C++11 on if the compiler supports it. The one I sent yesterday. #4 - see if that causes problems. fix problems. maybe revert patch from step #3 if problems are hard to solve quickly. #5 - flip to consider C++11 mandatory. Make configure error out if no C++11 compiler is found. #6 - see what workflows break (e.g., see if we need to do anything with some buildslaves. #6.a - if $problem, revert patch from step #5. fix whatever workflows, and goto #5. #7 - otherwise, after some period, start using C++11 in full. Remove the shim and do s/gdb::unique_ptr/std::unique_ptr/g throughout the code base. All the while between #1 and #7, we can progressively convert cleanups to use gdb::unique_ptr. Ie., we'd pipeline/paralyze the work. > The only other thing we need to agree is that we are not going to > switch to a C++ standard newer than C++11, and won't allow code that > doesn't compile with C++11 compilers, until the oldest compiler which > supports that newer standard is at least 3 years old (like GCC 4.8.1 > is today). Agreed. > Does this sound like a compromise everyone can live with? Thanks, Pedro Alves