From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76004 invoked by alias); 11 Oct 2016 19:23:56 -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 75974 invoked by uid 89); 11 Oct 2016 19:23:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=H*r:112, homemade, home-made, migrate X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 11 Oct 2016 19:23:51 +0000 Received: by simark.ca (Postfix, from userid 112) id 623981E131; Tue, 11 Oct 2016 15:23:49 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id EC7841E124; Tue, 11 Oct 2016 15:23:46 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 11 Oct 2016 19:23:00 -0000 From: Simon Marchi To: Eli Zaretskii Cc: Pedro Alves , brobecker@adacore.com, markus.t.metzger@intel.com, gdb-patches@sourceware.org Subject: Re: [PATCH 1/3] Introduce gdb::unique_ptr In-Reply-To: <831szmd977.fsf@gnu.org> 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> Message-ID: <4aba16c0ae13533cd9e93f0f2823b042@simark.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.2.0 X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00276.txt.bz2 On 2016-10-11 14:36, Eli Zaretskii wrote: >> 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. I don't think anybody has seriously suggested requiring C++11 any time soon, other than in a very hypothetical formulation. I can see why there are some misunderstanding, especially for those who haven't followed closely the C++ conversion. Let me try to state what I understand from the situation. C++03 has been around for long enough that we can safely migrate to that (whereas it has value or not is another debate, although I think Pedro showed clearly that it has), without leaving many users behind. C++11 comes with some nice features in its standard library, such as std::unique_ptr. std::unique_ptr has some improvements over the old std::auto_ptr, which was too easy to misuse. However, I think we all agree that C++11 would be a too aggressive change, and will still be for some time. What Pedro chose to do is to create gdb::unique_ptr, our home-made version of std::unique_ptr. When building with a C++03 compiler, the hand-written version of the code is chosen and it works (see the #if __cplusplus >= 201103). However, it's possible to misuse it, the same way as it was possible to misuse std::auto_ptr (because of missing features in C++03 vs C++11 IIUC). If you happen to build with a C++11 compiler, instead of choosing the hand-written version, gdb::unique_ptr is more or less an alias for std::unique_ptr. So if there is a place in the code that is misusing it, the build will fail and either buildbot or another developer will let us know promptly. So it's not that the code is built in a way which requires C++11, it's built in a way that if you use C++11, you get the benefits of the newer checking mechanisms, while still being able to build with a C++03 compiler. IMO it's the best of both worlds. Actually, it's the same idea as gnulib, where we fill the gaps of the lacking platforms, rather than choosing a low common denominator. The warning analogy was perhaps not clearly expressed but I think it was good. Let's say somebody with an old compiler wrote this code: void foo() { int a; global = a; } The old compiler doesn't have a warning to tell you that "a" is being used without being initialized, so it accepts it. When another developer, with a newer compiler, tries to build gdb, he/she gets an error, and is able to report the bug. With unique_ptr, it's similar. Somebody with an old compiler gets less compiler checking. The difference is that we need to write a bit of code (this patch) to bridge the gap, whereas with warnings it comes for free.