From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107471 invoked by alias); 11 Oct 2016 20:54:49 -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 107454 invoked by uid 89); 11 Oct 2016 20:54:48 -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=homemade, sticking, home-made, migrate 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 20:54:38 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bu44H-0005Hc-Cw for gdb-patches@sourceware.org; Tue, 11 Oct 2016 16:54:36 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43283) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bu44H-0005HU-9c; Tue, 11 Oct 2016 16:54:33 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1974 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bu44F-0005Pe-CC; Tue, 11 Oct 2016 16:54:31 -0400 Date: Tue, 11 Oct 2016 20:54:00 -0000 Message-Id: <83twcibo91.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: <4aba16c0ae13533cd9e93f0f2823b042@simark.ca> (message from Simon Marchi on Tue, 11 Oct 2016 15:23:46 -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> 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/msg00278.txt.bz2 > Date: Tue, 11 Oct 2016 15:23:46 -0400 > From: Simon Marchi > Cc: Pedro Alves , brobecker@adacore.com, > markus.t.metzger@intel.com, gdb-patches@sourceware.org > > 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. Then why was there talk to use -std=gnu++11? > 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. 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. 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. > The warning analogy was perhaps not clearly expressed but I think it was > good. No, it wasn't: warnings don't affect code at all. This suggestion clearly will.