From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72400 invoked by alias); 11 Oct 2016 18:37:00 -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 72370 invoked by uid 89); 11 Oct 2016 18:36:59 -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=happier, reread, trade 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; Tue, 11 Oct 2016 18:36:49 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bu1ut-0001cy-TE for gdb-patches@sourceware.org; Tue, 11 Oct 2016 14:36:47 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41565) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bu1ut-0001cX-PR; Tue, 11 Oct 2016 14:36:43 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1861 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bu1ur-0002ED-Rh; Tue, 11 Oct 2016 14:36:42 -0400 Date: Tue, 11 Oct 2016 18:37:00 -0000 Message-Id: <831szmd977.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves CC: brobecker@adacore.com, markus.t.metzger@intel.com, gdb-patches@sourceware.org In-reply-to: <4d49eb8f-5a0c-1e7e-d082-1a224179184f@redhat.com> (message from Pedro Alves on Tue, 11 Oct 2016 18:41:01 +0100) Subject: Re: [PATCH 1/3] Introduce gdb::unique_ptr Reply-to: Eli Zaretskii References: <1476117992-5689-1-git-send-email-palves@redhat.com> <1476117992-5689-2-git-send-email-palves@redhat.com> <20161011121639.GE3813@adacore.com> <68fc02cb-59bc-012c-d1be-b5ed2076d6a5@redhat.com> <20161011144741.GF3813@adacore.com> <83insydifw.fsf@gnu.org> <83a8eadds7.fsf@gnu.org> <4d49eb8f-5a0c-1e7e-d082-1a224179184f@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/msg00273.txt.bz2 > Cc: brobecker@adacore.com, markus.t.metzger@intel.com, > gdb-patches@sourceware.org > From: Pedro Alves > Date: Tue, 11 Oct 2016 18:41:01 +0100 > > On 10/11/2016 05:57 PM, Eli Zaretskii wrote: > > >> That's a misunderstanding. Full C++11 support is available > >> in gcc 4.8 already. > > > > Yes, I know. I'm just envisioning that once we require to build GCC, > > we will soon require a new enough version of it. Like Joel says: > > That still sounds like a misunderstanding, because we're not > requiring that you build GCC. Maybe it is indeed a misunderstanding, but then perhaps you could re-read what you and Joel were saying, to see how such a misunderstanding could happen, and avoid saying things in the future that could be misinterpreted. > We're talking about requiring C++11 support. There's a difference. > If you don't have a compiler that supports C++11, _then_ you'd have > to build one. As long as we stay with C++11, I have no problem (although it does look like a huge jump, which we perhaps should have taken more slowly, and stay with C++03 for now). My problem begins where we will in a few months jump so easily to C++14 and whatever else is after that. I see no reason not to fear this, do you? Where are the rules and decisions that we won't? > That is, we're mainly talking about the trade off between getting > access to C++11 and how that would improve the codebase and > maintainability vs convenience of getting a new gdb built on an > older system with an old system compiler. Please don't forget that you look at these problems from the POV of someone who always have the newest tools available. I'm trying to keep these decisions in their proper perspective by taking a POV of someone whose tools are one or 2 major GCC releases older. > > I see where it's going, and I don't like it. We will make it hard on > > users to build GDB. Just 7 months ago all you needed was a C90 > > compiler, and look where we are now. > > There's no sekrit conspiracy here. I didn't think there were a conspiracy. But that doesn't help, does it? Such slippery slopes are known human tendency, the only way to avoid that is not to step on the slope in the first place. > > If we stay with 4.8 for long enough, I have no problem. But we must > > record this decision somewhere and stick to it, because otherwise it > > will be one more domino to fall, and soon enough. > > Yes, of course if we move forward with a requirement change we'll > document it. I think we need to document that before we more forward. Otherwise we won't know whether we are moving forward or not, and won't know to stop and think a bit before we do. > It'll naturally end up reevaluated at some point, maybe years from > now. The jump from C++03 -> C++11 is _huge_. C++11 -> C++14 not > that much. Then maybe we shouldn't make that huge jump, not just yet. It was never discussed seriously, AFAIK. > >> I don't expect anyone to _have_ to build any mingw compiler to be able > >> to build gdb for mingw. > > > > If you suddenly require 6.x or 7.x, they will have no choice. > > Well, that's (an unintended, no doubt) strawman, because no one is > suggesting that. That's not how I read your messages. Apologies for my misunderstanding, but I can show you how your words actually made that sound as if you were. > I'll make an analogy. Think of it as if GCC 6.x enabled some > useful warning flag by default that used to be disabled by default. I don't think it's a good analogy. You are not talking about warning switches, are you? > First, it's not true that these C++ changes have not been planned. > They've been part of the plan ever since the very beginning. See > here, step 5 of the original version of the plan I originally > circulated in 2014: > > https://sourceware.org/gdb/wiki/cxx-conversion?action=recall&rev=1 > > Current version is here: > > https://sourceware.org/gdb/wiki/cxx-conversion#Transition_plan > > Note the not-done-yet bullet points in step 8 (step 5 in rev 1). > That's exactly what's going on right now. Where does it say that we should require C++11? Or any specific version of the C++ standard, for that matter? AFAIR, this was never discussed. > > But I don't want to argue about C++, that was just an example of a > > slippery slope similar to what I fear will happen once we require a > > new enough GCC to be able to compile GDB. I think that would be a bad > > mistake. > > Again, no one's proposed that. Heck, until today I was under the > impression that gcc 4.8 was too new and had assumed proposing to require > that for C++11 would be out of question. But I'm very happy to > learn that I've been mistaken! I'd still be happier if you were not mistaken.