From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33238 invoked by alias); 12 Oct 2016 06:23:28 -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 33220 invoked by uid 89); 12 Oct 2016 06:23:27 -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=honesty, admitted, Previously, HContent-type:iso-8859-1 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 06:23:17 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buCwZ-0001Ck-Mr for gdb-patches@sourceware.org; Wed, 12 Oct 2016 02:23:15 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50232) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buCwZ-0001C7-JN; Wed, 12 Oct 2016 02:23:11 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2380 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1buCwX-0000SY-JK; Wed, 12 Oct 2016 02:23:10 -0400 Date: Wed, 12 Oct 2016 06:23:00 -0000 Message-Id: <83pon6axxa.fsf@gnu.org> From: Eli Zaretskii To: Simon Marchi CC: palves@redhat.com, brobecker@adacore.com, markus.t.metzger@intel.com, gdb-patches@sourceware.org In-reply-to: <3fae204de19f0105e6dcda05014ad96b@simark.ca> (message from Simon Marchi on Tue, 11 Oct 2016 17:28:24 -0400) 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> <4aba16c0ae13533cd9e93f0f2823b042@simark.ca> <83twcibo91.fsf@gnu.org> <3fae204de19f0105e6dcda05014ad96b@simark.ca> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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/msg00285.txt.bz2 > Date: Tue, 11 Oct 2016 17:28:24 -0400 > From: Simon Marchi > Cc: palves@redhat.com, brobecker@adacore.com, markus.t.metzger@intel.com, > gdb-patches@sourceware.org > > On 2016-10-11 16:54, Eli Zaretskii wrote: > > Then why was there talk to use -std=gnu++11? > > For those compilers that support C++11, but default to C++03. If the > feature is present and using it provides use with better error-checking, > why not use it? You are contradicting yourself. Previously, you said: > However, I think we all agree that C++11 would be a too aggressive > change, and will still be for some time. Now you are saying that we _should_ use C++11? Do you see how confusing all this is? I cannot even figure out what is it that people are arguing for or against. > > That's not "stick to C++03" in my book. Sticking to C++03 means not > > writing any code that requires a later standard at all. > > That's your interpretation. I prefer to interpret it as compilable with > a C++03 compiler, with no significant difference in the resulting > behaviour. > > > Exactly like > > we did when we required C90, but not C99: we had no code written for > > C99 compilers, #ifdef'ed away for C90 compilers. Everything was C90. > > Maybe because there wasn't a need or reason to do so? In this case, > there appears to be some value doing it. Do you question the fact that > it brings value at all, or that that value is not worth the extra > complexity? I question the honesty of the decision not to switch to standards supported only by recent versions of GCC. There's always a shining new version of the standards out there, which is normally much better than the previous ones. By that logic, we should switch to the latest version of standard C++ the moment it appears in draft, because it definitely brings some significant value. > I am sure nobody wants to see the whole code base sprinkled with such > #ifs. But here it's isolated in a file that we'll almost never touch > again, and which will significantly improve the rest of the code base, > with which we work with daily. Once admitted into the sources and allowed as acceptable practice, this will never remain limited to a single file. Let's not be naïve.