From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20644 invoked by alias); 13 Oct 2016 14:46:40 -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 20619 invoked by uid 89); 13 Oct 2016 14:46:38 -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=onetime, one-time, premise, convincing 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 14:46:28 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buhH4-0006Gb-T1 for gdb-patches@sourceware.org; Thu, 13 Oct 2016 10:46:26 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49669) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buhH4-0006Fq-Py; Thu, 13 Oct 2016 10:46:22 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4564 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1buhH2-0002ce-RL; Thu, 13 Oct 2016 10:46:21 -0400 Date: Thu, 13 Oct 2016 14:46:00 -0000 Message-Id: <83lgxs8fyj.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves CC: tom@tromey.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org In-reply-to: (message from Pedro Alves on Thu, 13 Oct 2016 15:26:07 +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> 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/msg00371.txt.bz2 > Cc: tom@tromey.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org > From: Pedro Alves > Date: Thu, 13 Oct 2016 15:26:07 +0100 > > On 10/13/2016 02:52 PM, Eli Zaretskii wrote: > > > 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. > > It was decided in 2014 that we'd target C++03. We have not decided > yet to _require_ C++11. Then that comment is not yet relevant. But then I think we should not use C++11 code in GDB. > >> 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. > > They are not incompatible. C++03 code compiles with a C++11 compiler > just fine. Granted, I meant the other way around: use code that a C++11 compiler will compile, but not a C++03 compiler. > > 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. > > Yes, "all those shims". One file. And then cleaner code in thousands > of uses of the shim throughout the codebase. None of that > shim-using code needs to know what version of the standard is > being targeted. Take a look at patch #3 from the gdb::unique_ptr > series, and see for yourself. > > So I'll take that tradeoff, yes. Is this a one-time tradeoff, for this single patch? Or is this a policy? In the former case, I have no objections. In the latter case, the "one file" argument doesn't apply. > >>> 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, > > Of course not. > > > and so this is a burden for all of us, not just for you. > > You're automatically assuming it's a burden. I believe that's > false. It should be clear and agreed by all that maintaining two implementations for a single feature is more work than maintaining just one. > >> 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? > > I'm talking about adding a small utility that is going to be used > extensively throughout the codebase. A smart pointer is a central widget. > That mine was modeled on a C++11 feature should be seen as > a _good_ thing. The std::unique_ptr was so good that it made it > to the standard. Not a small feat. Bonus. Once we move on to C++11 > for real (I don't know when), then there's one less API to learn. 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. > >> 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? > > Of course. The problem is that your opinion is interpreted as > a hard blocker. The result is stalling. If there are no more convincing arguments, then a usual way out of stalling is to find some compromise. Is that possible in this case? > >> 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 > > And not "not necessarily" either... This just looks like fear of > the unknown, I'm afraid. What exactly is unknown here? It should be clear to anyone that more of such patches, with separate implementations for C++11 and C++03, will come soon enough. What reason do you have to think they won't? After all, C++11 is so much better than C++03, right? > > 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. > > As I've said before, we can make use of the buildbot for that. > If the fallback code breaks, you get an immediate email notification. If someone sets it up to build both with and without C++11, yes. A.k.a. "maintenance burden".