From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82603 invoked by alias); 11 Oct 2016 14:05:50 -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 82522 invoked by uid 89); 11 Oct 2016 14:05:50 -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,SPF_PASS autolearn=ham version=3.3.2 spammy=perception, frustrating, ime, Hx-languages-length:2026 X-HELO: paperclip.tbsaunde.org Received: from tbsaunde.org (HELO paperclip.tbsaunde.org) (66.228.47.254) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 11 Oct 2016 14:05:43 +0000 Received: from ball (unknown [174.88.174.231]) by paperclip.tbsaunde.org (Postfix) with ESMTPSA id AB769C06B; Tue, 11 Oct 2016 14:05:41 +0000 (UTC) Date: Tue, 11 Oct 2016 14:05:00 -0000 From: Trevor Saunders To: Pedro Alves Cc: "Metzger, Markus T" , "gdb-patches@sourceware.org" Subject: Re: [PATCH 1/3] Introduce gdb::unique_ptr Message-ID: <20161011140900.veexavju66u6mz4u@ball> References: <1476117992-5689-1-git-send-email-palves@redhat.com> <1476117992-5689-2-git-send-email-palves@redhat.com> <3cd38c85-fa55-35b5-8f3a-293ba7df82c9@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3cd38c85-fa55-35b5-8f3a-293ba7df82c9@redhat.com> User-Agent: NeoMutt/20160916 (1.7.0) X-SW-Source: 2016-10/txt/msg00254.txt.bz2 On Tue, Oct 11, 2016 at 12:43:09PM +0100, Pedro Alves wrote: > On 10/11/2016 12:16 PM, Metzger, Markus T wrote: > > > Wow, that was a long reply to such a small question. I was mainly > > wondering if it makes sense to write (and maintain) ones own version > > of a standard library feature. fwiw, I've been meaning to add this to gcc at some point for the same reasons. Since I doubt gcc is interested in requiring C++11 that will probably happen and it will stay around for a while either way. In addition its not terribly complex code, and I expect it won't change much. > > The big step was not supporting C any longer. Requiring C++11 looks > > small, by comparison. > > Agreed, from language perspective. The question is one of _compiler_ access > and convenience. But it looks like I might have been wrong in my previous > perception that dropping support for older GCCs would be unrealistic at > this point. I'd love to hear other's opinions. > > > BTW, I noticed that maintainers seem very busy these days and patches > > are waiting unusually long for review. > > Yeah. Myself, I don't really know nowadays what it means to not be very busy, and > also getting the 7.12 release/branch ready took me significant effort. Over the > past few releases, I've been considering whether an explicit "bugfixes/regressions > only" state, like gcc's stages would help -- because what happens is that > people send in patches for master and the pings and if they're not following > development closely, they won't realize the reason people are not > looking at their patches is the focus on the release, and everyone is > frustrated. At least I am. Personally I find the gcc setup frustrating too, and I imagine its a real pain if you just want to get one patch in. The ideal answer is probably get more people who can review, with enough people the cut branches and keep developing trunk seems to work well enough ime, but I'm definitely busy ;) Trev > > Thanks, > Pedro Alves >