From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127018 invoked by alias); 12 Oct 2016 10:12:08 -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 125432 invoked by uid 89); 12 Oct 2016 10:12:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Oct 2016 10:11:56 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 449357F7B9; Wed, 12 Oct 2016 10:11:55 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9CABo4g008391; Wed, 12 Oct 2016 06:11:50 -0400 Subject: Re: [PATCH 1/3] Introduce gdb::unique_ptr To: Eli Zaretskii , "Metzger, Markus T" 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> <831szmd977.fsf@gnu.org> <83vawybol4.fsf@gnu.org> <6ba388f7-1696-42db-ae92-23df79e3ba11@redhat.com> <83oa2qaxe7.fsf@gnu.org> <83insxc3rv.fsf@gnu.org> Cc: brobecker@adacore.com, gdb-patches@sourceware.org, jan.kratochvil@redhat.com, simon.marchi@ericsson.com From: Pedro Alves Message-ID: <444c7c47-f23b-bb95-aa36-dbb1544142f3@redhat.com> Date: Wed, 12 Oct 2016 10:12:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <83insxc3rv.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00293.txt.bz2 On 10/12/2016 10:31 AM, Eli Zaretskii wrote: >> From: "Metzger, Markus T" >> CC: "brobecker@adacore.com" , >> "gdb-patches@sourceware.org" , "Jan Kratochvil >> (jan.kratochvil@redhat.com)" , Simon Marchi >> >> Date: Wed, 12 Oct 2016 08:11:44 +0000 >> >> I think we got hung up on the perceived requirement of having to build >> your own GCC. The discussion got a bit too abstract and mentioning GCC 6 >> as the first to default to C++11 may have been confusing in the heat of the >> discussion as "GCC 6 defaults to C++11" may have been misread as "C++11 >> requires GCC 6". > > I don't think that's what happened. In my interpretation, there are > simply several issues intertwined in this discussion (which probably > adds to confusion): > > . Should we start using C++11 features in GDB? I would hope that no one would suggest that we shouldn't use C++11 features just because they like C++03 better than C++11. That would make no sense. In my mind, the only reason you'd not use C++11 over C++03 is simply because you couldn't because you don't have a compiler that supports it. IMO, at this point, the number of systems that don't have a C++11 compiler handy AND where you'd absolutely need to build a new GDB is sufficiently small that the desire to use C++11 features overwhelms the inconvenience of having to build a new compiler first, on those specific cases. Many of the larger projects around the free software community require C++11 nowadays. It's quite likely that even on older systems you'll have arranged to set up a newer compiler that supports C++11, because it is dependency on the programs that you'll likely want to debug with gdb. Alternatives to GDB, like lldb, already require a C++11 compiler anyway, so C++11 alone won't be a reason that would cause people to try alternatives on those systems. But even if we don't _require_ C++11, IMO, yes, we should still use select C++11 features when available, in implementation details of gdb's general utilities, when they add extra safety or efficiency that is simply not possible in C++03. TBC, I would reject patches that added: #if cxx11 ... #else ... #endif sprinkled around the codebase in non-utility code. > . Should we document these decisions and also decide to abide by > them for some reasonably long stretch of time? Sure, we should document the decisions. But I see no point in locking ourselves to past decisions on a timed basis. Past decisions should be reevaluated simply when they longer make sense. I.e., apply past reasoning to current reality and see if the same answer comes out. Thanks, Pedro Alves