Re: [PATCH 1/5] Introduce specialized versions of gdbpy_ref

[Pedro Alves <palves at redhat dot com>]

On 01/23/2017 10:40 PM, Simon Marchi wrote:
> 
> We must make sure to only use gdbpy_ref_base on objects that actually
> are Python objects.  For example, gdbpy_ref_base<thread_info> would make
> not sense.  Since the "inheritance" from the PyObject type is done in a
> C way (using PyObject_HEAD), I don't know how we can check at
> compile-time that we are not using it with a wrong type.  If you have an
> idea on how to do that, let me know.  We would need to check that there
> exists a field named ob_base.  Bonus points for ensuring that its type
> is PyObject.  More bonus points for ensuring that it's the first field
> in the structure.

You can do all this with SFINAE.  For the "is first field check, you could
use something like "(PyObject*) this == &this->ob_base" as expression,
I think.

https://en.wikipedia.org/wiki/Substitution_failure_is_not_an_error

There are many examples around the web, if you search for SFINAE and
"C++ check if member exists", etc.  E.g,:

http://stackoverflow.com/questions/1005476/how-to-detect-whether-there-is-a-specific-member-variable-in-class

Though I still wonder whether just inheriting our objects from
PyObject wouldn't make things simpler.

> For convenience, I added a get_py_obj method to gdbpy_ref_base, which
> returns the pointer casted to PyObject*, something we need to do
> relatively often).

Thanks,
Pedro Alves