From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76829 invoked by alias); 13 Oct 2016 06:11:56 -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 76692 invoked by uid 89); 13 Oct 2016 06:11:55 -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=workarounds, iow, Hx-languages-length:1213, threaten 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 06:11:45 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buZEx-0004BR-Ko for gdb-patches@sourceware.org; Thu, 13 Oct 2016 02:11:42 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43217) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buZEx-0004B9-HL; Thu, 13 Oct 2016 02:11:39 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3960 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1buZEv-00013g-5T; Thu, 13 Oct 2016 02:11:37 -0400 Date: Thu, 13 Oct 2016 06:11:00 -0000 Message-Id: <8337k0aicw.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves CC: tom@tromey.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org In-reply-to: <2855e2ec-46dc-71b7-9943-8edaebcbef90@redhat.com> (message from Pedro Alves on Thu, 13 Oct 2016 02:28:44 +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> 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/msg00345.txt.bz2 > Cc: Simon Marchi , gdb-patches@sourceware.org > From: Pedro Alves > Date: Thu, 13 Oct 2016 02:28:44 +0100 > > Yeah, sounds right. I was trying get the gdb::unique_ptr in, in order > to unblock the cases I suggested you use unique_ptr, but I'm a bit > confused on what to do about it now... I _think_ people are generally > OK with it. There was some opposition, but I'm not sure anymore > whether it still exists. C++11 is now on the table, but maybe a > staged approach (enable C++11 while supporting C++03 too for a while, > to catch issues) would make sense anyway. I still think we shouldn't have workarounds for versions of the standard older than what we want to support. IOW, if we decide to use C++11, we should _require_ a compiler that supports it, and error out if the configure test(s) regarding that fail. Supporting more than one standard means we will have rarely used code that is almost never tested, and that means maintenance burden which threaten to undo at least some part of the benefits you aspire to achieve by moving to C++ in general and to a new enough C++ standard in particular.