From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26477 invoked by alias); 12 Oct 2016 11:05:09 -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 26461 invoked by uid 89); 12 Oct 2016 11:05:08 -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=principles, quantitative, qualitative, criteria 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; Wed, 12 Oct 2016 11:04:58 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buHLD-00078f-Ha for gdb-patches@sourceware.org; Wed, 12 Oct 2016 07:04:56 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53888) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buHKv-00072B-Vl; Wed, 12 Oct 2016 07:04:38 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2831 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1buHKu-0001Uc-Lw; Wed, 12 Oct 2016 07:04:37 -0400 Date: Wed, 12 Oct 2016 11:05:00 -0000 Message-Id: <83eg3lbzgm.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves CC: markus.t.metzger@intel.com, brobecker@adacore.com, gdb-patches@sourceware.org, jan.kratochvil@redhat.com, simon.marchi@ericsson.com In-reply-to: <444c7c47-f23b-bb95-aa36-dbb1544142f3@redhat.com> (message from Pedro Alves on Wed, 12 Oct 2016 11:11:50 +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> <831szmd977.fsf@gnu.org> <83vawybol4.fsf@gnu.org> <6ba388f7-1696-42db-ae92-23df79e3ba11@redhat.com> <83oa2qaxe7.fsf@gnu.org> <83insxc3rv.fsf@gnu.org> <444c7c47-f23b-bb95-aa36-dbb1544142f3@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/msg00297.txt.bz2 > Cc: brobecker@adacore.com, gdb-patches@sourceware.org, > jan.kratochvil@redhat.com, simon.marchi@ericsson.com > From: Pedro Alves > Date: Wed, 12 Oct 2016 11:11:50 +0100 > > > . 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. It would make perfect sense if we decide to require a version of GCC older than 4.8.1 as a prerequisite for building GDB. > 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. These are qualitative arguments. We need a quantitative criteria for when to raise the bar for the minimum supported language standard. Such a criterion could be the number of years since the release of the GCC version that fully supports that standard. If this is an acceptable criterion, can we talk about the number of years we would like to set up as the quantitative parameter here? Can we then commit ourselves to upholding that criterion for the observable future? > Many of the larger projects around the free software community > require C++11 nowadays. And many still support C90. E.g., Emacs started requiring C99 in version 25.1, released just a month ago. GNU Make still supports C90, as does Gawk. So I don't think this is a useful argument, because there are examples either way. > 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. If these features are supported by whatever versions of the compiler we decide to require, I agree. > TBC, I would reject patches that added: > > #if cxx11 > ... > #else > ... > #endif > > sprinkled around the codebase in non-utility code. Agreed. > > . 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. "No longer make sense" is again too vague to be efficient in preventing arguments like this one. We should decide on firm principles and stick to them. Even if that means we will keep the bar lower for longer than absolutely necessary (and it doesn't have to mean that), that's hardly a catastrophe.