This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA 1/8] Add gdb_ref_ptr.h


On 12/02/2016 05:46 PM, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
> 
> Pedro> Can you please remove them and see what breaks?  Odd that this would be
> Pedro> something about Python, given the class is being used in Python code
> Pedro> today?
> 
> Yes, it's odd.  If I comment out the nullptr_t overloads, I get build
> failures like:
> 
> ../../binutils-gdb/gdb/python/py-exitedevent.c:31:20: error: no match for ‘operator==’ (operand types are ‘gdbpy_ref {aka gdb::ref_ptr<_object, gdbpy_ref_policy>}’ and ‘long int’)
>    if (exited_event == NULL)
>                     ^
> ../../binutils-gdb/gdb/common/gdb_ref_ptr.h:183:13: note:   template argument deduction/substitution failed:
> In file included from ../../binutils-gdb/gdb/python/py-ref.h:23:0,
>                  from ../../binutils-gdb/gdb/python/py-event.h:27,
>                  from ../../binutils-gdb/gdb/python/py-event.c:21:
> ../../binutils-gdb/gdb/common/gdb_ref_ptr.h:171:13: note: candidate: template<class T, class POLICY> bool gdb::operator==(const T*, const gdb::ref_ptr<T, POLICY>&)
>  inline bool operator== (const T *self, const ref_ptr<T, POLICY> &other)
>              ^~~~~~~~
> 
> 
> I don't understand why it picks this particular candidate, but

I think gcc will list you all candidates, mentioning why each one
can't work.  I.e., it likely tells you more further below?

> re-reading it now I think my earlier theory is wrong.

Does it still happen if you remove the cstddef include?

Do you have your code in some branch?  It seems none of the
gdbpy_ref stuff is in master yet.

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]