AW: AW: [C++-sig] Wrapping opaque pointers returned from API func tion s

[David Abrahams]

Gottfried.Ganssauge at HAUFE.DE writes:

>> -----Ursprungliche Nachricht-----
>> Von: David Abrahams [mailto:dave at boost-consulting.com]
>> Gesendet: Montag, 13. Januar 2003 13:47
>> An: c++-sig at python.org
>> Betreff: Re: AW: [C++-sig] Wrapping opaque pointers returned from API
>> function s
>> 
>> 
>> Gottfried.Ganssauge at HAUFE.DE writes:
>> 
>> >> I didn't say I tested the code ;-)
>> >
>> > Of course.
>> > Anyway, your upcast is probably invalid anyway, because 
>> PyObject ist not a
>> > base class of instance.
>> 
>> No, it is not invalid.  My upcast template is specially designed to
>> deal with this.  Please try doing as I suggested.
> Here you are:
> c:\daten\devel\boost\boost\python\cast.hpp(31) : error C2039: 'type' : Ist
> kein Element von 'base_type_traits<struct convert_opaque_pointer<struct
> workspace_ *>::instance>'
> c:\daten\devel\boost\boost\python\cast.hpp(52) : Siehe Verweis auf
> Instantiierung der kompilierten Funktionsvorlage 'struct _object *__cdecl
> boost::python::detail::upcast(struct convert_opaque_pointer<struct
> workspace_ *>::instance *,int *,int *,struct _object *)'
>
> I had seen that message before and concluded from it, that
> convert_opaque_pointer<struct workspace_ *>::instance * can't be converted
> to PyObject * using upcast<>.

Ah, sorry.  You'd need to specialize
boost::python::base_type_traits<instance>... and that comes with
portability complications of its own.  So a plain C-style cast is just
fine.

>> 
>> >> No, that's non-POD.  It has a base class.  
>> >
>> > I think I have a solution that is hopefully more conforming 
>> but doesn't rely
>> > on the Python implementation details (and it even resembles 
>> a bit to real
>> > inheritance)
>> > 	struct instance {
>> > 		PyObject base_;
>> > 		Pointer x;
>> > 	};
>> 
>> The contents of PyObject are still Python implementation details.
> True, but I don't use it. PyObject_HEAD may be the implementation of
> PyObject but there is no direct relationship between the two except Guido.
> (no criticism; just a fact)
>
>> This one is no better than my proposal, and may in fact take extra
>> storage for alignment.
> At least it doesn't need a cast :-)

OK.

> Why should there be extra alignment storage used after PyObject but not
> after PyObject_HEAD?

Because sizeof(PyObject) has to be arranged so that the first element
of the next PyObject in an array can be aligned.  That could imply
padding at the end which the Pointer element might have fit into.
It's a minor detail.

> My solution only uses the fact, that there is no extra padding before the
> base_ member so that a pointer to base_ may be returned from the convert
> method that can be converted back to a pointer to our instance struct.

Your solution is fine.

Thanks for all your work on this!

-- 
                       David Abrahams
   dave at boost-consulting.com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution