From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59491 invoked by alias); 13 Oct 2016 15:19:53 -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 59429 invoked by uid 89); 13 Oct 2016 15:19:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=policy X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Oct 2016 15:19:42 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buhnF-0006lS-I6 for gdb-patches@sourceware.org; Thu, 13 Oct 2016 11:19:40 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50073) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buhnF-0006lO-EO; Thu, 13 Oct 2016 11:19:37 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4592 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1buhnE-0001I3-Jo; Thu, 13 Oct 2016 11:19:37 -0400 Date: Thu, 13 Oct 2016 15:19:00 -0000 Message-Id: <83k2dc8ef4.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves CC: tom@tromey.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org In-reply-to: <9d9dca17-56a6-6c0a-44bb-efc425f24d8d@redhat.com> (message from Pedro Alves on Thu, 13 Oct 2016 16:04:05 +0100) Subject: Re: [RFA 09/22] Remove make_cleanup_restore_current_ui Reply-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> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00377.txt.bz2 > Cc: tom@tromey.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org > From: Pedro Alves > Date: Thu, 13 Oct 2016 16:04:05 +0100 > > On 10/13/2016 03:46 PM, Eli Zaretskii wrote: > > And I'm again asking whether this is about this single patch, or about > > a more general policy. I assume that it's the latter, in which case > > we are not talking about a single small utility, we are talking about > > all the code that will be in the future admitted to GDB with the same > > premise. It is the policy that I object to, not a single exception. > > I don't have an answer simply because I don't know what we'll > need in the future. If we agree on some policy, then we don't need to worry about the future, because the policy will determine what is going to be admitted and what not. > 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. 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). Does this sound like a compromise everyone can live with?