[C++-sig] Re: Exposing C++ objects to Python at runtime
David Abrahams
dave at boost-consulting.com
Tue Nov 25 18:09:43 CET 2003
Raoul Gough <RaoulGough at yahoo.co.uk> writes:
> 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,
Unless you want to do it the hard way, yeah ;-)
> but you would gain some decoupling from the actual registration
> code.
Yeah. I can even imagine that this arrangement would speed up
compile times...
>> 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.
Yup.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
More information about the Cplusplus-sig
mailing list