[C++-sig] Re: Exposing C++ objects to Python at runtime

[Daniel Wallin]

Raoul Gough wrote:
> Daniel Wallin <dalwan01 at student.umu.se> writes:
> 
> 
>>Raoul Gough wrote:
>>
>>>Daniel Wallin <dalwan01 at student.umu.se> writes:
> 
> [snip]
> 
>>
>>The code which does the actual conversion is separated from the function
>>descriptor. perform_conversion() is completetly language dependent and
>>just an implementation detail in this case.
> 
> 
> The point I'm trying to make is that I believe the code in
> perform_conversion (at some point down the call chain) has to have
> compile-time knowledge of the C++ type. This means that a simple
> abstract base class interface will not suffice (at least, not one that
> is independent of the scripting language in question).

Custom converters aside, there are really very few conversion left that
depend on the wrapped language; conversions to/from primitive types, and
conversions to/from UDT's wrapped with class_<>. The UDT conversion is
only dependent on the wrapped language in that it needs to be able to
extract a void* to the UDT object from the argument, it doesn't require
any compile time knowledge to generate code that depends on the
language.

>>>function<...>::convert_argument0 (PyObject *src, void *dst) {
>>>  // create an arg_vector<0> type from PyObject at dst
>>>}
>>>function<...>::convert_argument0 (lua_State *src, void *dst) {
>>>  // create an arg_vector<0> object from lua_State at dst
>>>}
>>
>>That isn't necessary. function doesn't need to care about what the
>>source type is, it just supplies the argument type_info's and invokes a
>>function on a list of argument objects.
> 
> 
> On a list of C++ arguments? I can agree with that, but I don't
> understand how those C++ arguments are generated without somebody who
> understands the scripting langauge objects also knowing what C++ types
> are involved.

The scripting language obviously has to have converters written to
convert primitive types.

> [snip]
> 
>>>But where does the C++ code for the converter (with compile-time
>>>knowledge of the C++ types) come from?
>>
>> From anywhere the language backend wants. It doesn't matter, the only
>>thing that matters is that the scripting backend is capable of
>>generating instances of some types, given by const type_info*'s.
> 
> 
> I don't see how a type_info object will allow you to create an
> instance of the class it represents. All it gives you is the
> following:
> 
> class type_info { 
> public: 
> virtual ~type_info(); 
> bool operator==(const type_info& rhs) const; 
> bool operator!=(const type_info& rhs) const; 
> bool before(const type_info& rhs) const; 
> const char* name() const; 
> private: 
> type_info(const type_info& rhs); 
> type_info& operator=(const type_info& rhs); 
> }; 
> 
> So the scripting language dependant backend receives the type_info,
> looks it up in its own data structures and then calls some code that
> knows how to convert a PyObject * (or whatever) into the UDT. My
> question is, where does that called code come from?

Like I said, in the case of a primitive type; from the language backend.
In the case of a UDT (non-custom converter), extract void* and use
language independent code to do the casts or instantiate the object.

>>We don't really need that much compile time knowledge to perform most
>>conversions. For instance, all UDT conversions for types registered by
>>class_<> goes through the same converter.
> 
> 
> ... which dispatches via its own lookup tables to code generated from
> scripting language dependant templates. For instance, take a look at
> boost/python/object/make_instance.hpp

I know how the conversion process works. Just because the code you 
referred to couples Python-calls with the code to instantiate the C++ 
type in a holder doesn't mean it has to be that way.

> I'm not trying to say that there is no scope for some compile-time
> decoupling between the scripting engine and the registration code,
> just that it will never be complete.

If we ignore custom converters (which would need to be written
separatly for every language backend) and policies, I think it could be.

-- 
Daniel Wallin