From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27886 invoked by alias); 2 Dec 2016 23:45:51 -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 27874 invoked by uid 89); 2 Dec 2016 23:45:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=overload, policy 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; Fri, 02 Dec 2016 23:45:48 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 863CD43A2C; Fri, 2 Dec 2016 23:45:47 +0000 (UTC) Received: from [127.0.0.1] (ovpn03.gateway.prod.ext.phx2.redhat.com [10.5.9.3]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB2NjjbW031244; Fri, 2 Dec 2016 18:45:46 -0500 Subject: Re: [RFA 1/8] Add gdb_ref_ptr.h To: Tom Tromey References: <1480395946-10924-1-git-send-email-tom@tromey.com> <1480395946-10924-2-git-send-email-tom@tromey.com> <87pola8bs7.fsf@tromey.com> <87k2bi85x8.fsf@tromey.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Fri, 02 Dec 2016 23:45:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <87k2bi85x8.fsf@tromey.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SW-Source: 2016-12/txt/msg00122.txt.bz2 On 12/02/2016 07:52 PM, Tom Tromey wrote: >>>>>> "Pedro" == Pedro Alves writes: > > Pedro> I think gcc will list you all candidates, mentioning why each one > Pedro> can't work. I.e., it likely tells you more further below? > > Yeah, it does, I missed that. Ah, trying locally and getting at the compile log helped. The overload we'd expect to work, doesn't: ..../src/gdb/solib-darwin.c: In function ‘void darwin_solib_get_all_image_info_addr_at_init(darwin_info*)’: ..../src/gdb/solib-darwin.c:467:16: error: no match for ‘operator!=’ (operand types are ‘gdb_bfd_ref_ptr {aka gdb::ref_ptr}’ and ‘long int’) if (dyld_bfd != NULL) ^ [...] ..../src/gdb/common/gdb_ref_ptr.h:212:13: note: candidate: template bool gdb::operator!=(const gdb::ref_ptr&, const T*) inline bool operator!= (const ref_ptr &self, const T *other) ^ ..../src/gdb/common/gdb_ref_ptr.h:212:13: note: template argument deduction/substitution failed: ..../src/gdb/solib-darwin.c:467:19: note: mismatched types ‘const T*’ and ‘long int’ if (dyld_bfd != NULL) ^ [...] That's simply because template type deduction, which happens before overload resolution, does not consider implicit conversions. And then there's no overload in the overload set that satisfied the operation. Before the gdb_ref_ptr.h patch (this email thread), gdbpy_ref is not a template, so: inline bool operator!= (const gdbpy_ref &self, const PyObject *other); is left in the overload set, at which point implicit conversions can apply. I was a bit mystified about why my gdb_unique_ptr shim had == NULL working without nullptr_t overloads, but I remember now. It was because it was using the safe bool idiom to make it work. I.e., adding this to ref_ptr would make operator==/operator!= work without the nullptr_t overloads too: /* "explicit operator bool ()" emulation using the safe bool idiom. */ private: typedef void (ref_ptr::*explicit_operator_bool) () const; void this_type_does_not_support_comparisons () const {} public: operator explicit_operator_bool () const { return (m_obj != NULL ? &ref_ptr::this_type_does_not_support_comparisons : 0); } With this, despite the fact that no operator== candidate template matches, the compile still manages to call the built-in, non-template: bool operator==(member function ptr, long); > Pedro> Do you have your code in some branch? It seems none of the > Pedro> gdbpy_ref stuff is in master yet. > > I pushed it to py-cxx-changes on my github account. Thanks, that helped. So the conclusion is that the nullptr_t overloads are necessary because ref_ptr is now a template. BTW, notice that both retain_ptr (that proposal I linked to), and unique_ptr have these same overloads. Thanks, Pedro Alves