From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69064 invoked by alias); 13 Oct 2016 13:53:23 -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 69023 invoked by uid 89); 13 Oct 2016 13:53:19 -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=sight, misses, unclear, betting 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 13:53:09 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bugRT-0003ld-3p for gdb-patches@sourceware.org; Thu, 13 Oct 2016 09:53:07 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49054) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bugRT-0003kx-03; Thu, 13 Oct 2016 09:53:03 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4442 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bugRQ-0005tU-UI; Thu, 13 Oct 2016 09:53:01 -0400 Date: Thu, 13 Oct 2016 13:53:00 -0000 Message-Id: <83r37k8ifg.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves CC: tom@tromey.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org In-reply-to: <6f27db2e-4b88-b72a-5836-080c3583eb7f@redhat.com> (message from Pedro Alves on Thu, 13 Oct 2016 11:16:26 +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> 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/msg00361.txt.bz2 > Cc: tom@tromey.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org > From: Pedro Alves > Date: Thu, 13 Oct 2016 11:16:26 +0100 > > On 10/13/2016 07:11 AM, Eli Zaretskii wrote: > >> 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. > > That is not what the patch does... I wasn't referring to the patch, I was referring to the quoted part of your message, specifically to this: > >> 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. > So again: > > > I still think we shouldn't have workarounds for versions of the > > standard older than what we want to support. > > there's no workaround for versions older than what we want to support > at all. Since I'm still unclear what is the oldest C++ standard we want to support, I cannot decide whether I agree or disagree. Is the version of the C++ standard we support C++03 or C++11? My comment assumed that it was C++11. > I'll give you more examples of why I think forbidding C++11 completely > is short sighted. Thanks, but that kind of arguments completely misses the point. You don't need to convince me that a later standard is better than the previous ones. The issue at hand is whether we should write code that targets more than a single language standard, where these standards aren't compatible. I think we shouldn't. > > Supporting more than one standard means we will have rarely used code > > that is almost never tested, and that means maintenance burden > > That same argument could be applied to gnulib. Or the many HAVE_FOO's > in the code base. We rely on gnulib's reimplementation of the whole > printf family of functions if the compiler doesn't support it properly > for example! I did apply it to gnulib at the time, but was voted down. Do you seriously consider the gnulib solution a good one? I don't. The code obfuscation is very significant. Of course, as long as you don't look into the gnulib headers, you don't care, but in this case you propose to have all those shims in our sources, in plain sight. > > that means maintenance burden > > For whom? _I'm_ willing to maintain this code. Are you saying that no one else will be allowed to modify the code which has 2 branches, one for C++03, the other for C++11? I'm betting you aren't saying that, and so this is a burden for all of us, not just for you. And that is even before we consider the "bus issue". > It's not rocket science code. Today it isn't. I'm not talking about this particular patch, I'm talking about this policy in general. As do you, I suppose: you aren't just asking for agreement about using C++11 features in this single case, right? > Several others have said they think this is a good idea. I've even > ran this idea through the libstdc++ maintainer in person at the Cauldron. > Trevor said he wants to do this in gcc as well. I just wanted to voice my opposition, that's all. I don't have to give up just because a few others think otherwise. Right? > If redirecting to C++11 std::unique_ptr turns out to cause trouble, or > I'm hit by a bus, then it's trivial to remove that redirection. All it > takes is remove a handful of lines of code guarded with > #if __cplusplus >= 201103 to always go through the fallback implementation. Once again, it's not just this single patch that bothers me. Once we have enough of these #if's, removing them is not necessarily a trivial matter, especially when most of the builds, perhaps even all of them, have been using the C++11 code path all the time, and the other one has simply bitrotted. > > 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. > > I don't understand what this is trying to say. The move to C++ was supposed to make the maintenance easier, right? I'm saying that targeting more than a single language standard makes maintenance harder, so it works against the purpose of the move. > And no, I'm not planning on getting hit by a bus. :-) Who is?