From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119621 invoked by alias); 10 Oct 2016 18:03:10 -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 119611 invoked by uid 89); 10 Oct 2016 18:03:09 -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 autolearn=ham version=3.3.2 spammy=mimics, skill, surprisingly, our X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 10 Oct 2016 18:02:59 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B15B6C05A2B8; Mon, 10 Oct 2016 18:02:58 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9AI2vHu027537; Mon, 10 Oct 2016 14:02:58 -0400 Subject: Re: [PATCH 1/3] Introduce gdb::unique_ptr To: Simon Marchi References: <1476117992-5689-1-git-send-email-palves@redhat.com> <1476117992-5689-2-git-send-email-palves@redhat.com> <238251ad623cb3a2f8532f07a15dd263@simark.ca> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Mon, 10 Oct 2016 18:03:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <238251ad623cb3a2f8532f07a15dd263@simark.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00229.txt.bz2 On 10/10/2016 06:49 PM, Simon Marchi wrote: > This is clearly way above my C++ skill level, I feel like I'm reading > boost code. Oh, boost has a unique_ptr emulation, and _that_ one is almost impenetrable. ;-) This version is trivial in comparison. That said, it has the advantage that is fully transparent on the "client" side, for routine usage. Other than std vs gdb namespace, that is. > But since it's well encapsulated in a "support" file and > mimics the standard behaviors, I think it's good. I just hope the whole > codebase won't end up lookup like this :). Yeah. This, just like the operator new patch, this is foundational work. A smart pointer is the major gaping hole right now. With this in place, I expect that we'll add lots of uses like in patches #2 and #3, but don't expect to need to touch the "library" code all that much or at all. > > On 2016-10-10 12:46, Pedro Alves wrote: >> - support for all of 'ptr != NULL', 'ptr == NULL' and 'if (ptr)' >> using the safe bool idiom. > > Since our coding style doesn't allow the "if (ptr)" form, is it possible > to make it cause a compile error? The point is that std::unique_ptr allows it, so I'd rather allow it in C++03 as well, otherwise we'd potentially introduce unnoticed build errors when developing with GCC >= 6. I found the need for that with patch #2 (expression_up). As soon as you convert a raw pointer to a smart pointer, all old code that was working with the raw pointer is now going through the smart pointer. And it's that old code that surprisingly has the "if (ptr)" form in several places. > >> +/* Base class of our unique_ptr emulation. Contains code common to >> + both the unique_ptr and unique_ptr. */ >> + >> +template >> +class unique_ptr_base : public safe_bool > >> +{ >> +public: >> + typedef T *pointer; > > pointer_type? That's part of the std::unique_ptr interface: http://en.cppreference.com/w/cpp/memory/unique_ptr Thanks, Pedro Alves