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

[Raoul Gough]

David Abrahams <dave at boost-consulting.com> writes:

> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
>
>> However, that implies detailed knowledge of the type of the member
>> function which (AFAICS) would only be available via function
>> template parameter deduction (and therefore impossible for a
>> virtual function).
>
> Of course.  You do that part of the work on the
> scripting-language-independent side of the abstraction barrier.  Just
> think about how Boost.Function
> + Boost.Bind makes a whole bunch of differently-typed callable things
> into the same type.

[from David Abrahams' earlier post]
>>>    struct function
>>>    {
>>>        virtual ~function() {}
>>>        virtual std::size_t arity() = 0;
>>>        virtual std::type_info const& result_type() = 0;
>>>        virtual std::type_info const* const* arg_types() = 0;
>>>        virtual void invoke(
>>>            void* const* args_storage, void* result_storage) = 0;
>>>    };

Oh, I get it - so you'd have a virtual function in the abstract base
class that accepts some kind of pointer-to-function object as an
argument? Each scripting engine would then extract the necessary
information from the function object instead of via template
parameters. You'd probably still need template parameter deduction to
generate the function object, but you would gain some decoupling from
the actual registration code.

>
>> Compile-time polymorphism would be a different matter, for
>> instance every class that wants to register itself with a scripting
>> engine could have a member function template like this:
>>
>> // ...
>>   template<typename ScriptEngine>
>>   static void register_self (ScriptEngine &engine) {
>>     engine.template register_class<self_type>(); // Or some such
>>     engine.register_nonstatic_memfn (function1);
>>     // ...
>>   }
>> };
>>
>> Might be handy I guess.
>
> I've been trying to say that you you *can*, in principle, still do
> this with a single ScriptEngine type, so that registration code gets
> compiled once, scripting-language-independently.

Given a certain amount of wrapper code to set up a "function
descriptor" object, I assume.

>
> I've also been trying to say that requiring coupling of the scripting
> engine registration into the classes being scripted is a mistake.

Sure. I recommended separating them in an earlier post.

-- 
Raoul Gough.
export LESS='-X'