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

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2017-02-09 06:58, Pedro Alves wrote:
> 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

Thanks!  This kind of thing doesn't come to me naturally yet.

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

I'll have to try that.

Thanks,

Simon