Re: [Implementation] Calling wrapped functions, converters, policies

Daniel Wallin <[email protected]> writes:

> David Abrahams wrote:
>> Daniel Wallin <[email protected]> writes:
>> 
>>>David Abrahams wrote:
>>>
>>>>Daniel Wallin <[email protected]> writes:
>>>
>>>
>>>>Yeah.  Ironically (?), I think needing to explode a single Python
>>>>argument to two C++ args is far more likely:
>>>>    void f(int count, char const** strings);
>>>>    >>> f(['foo', 'bar', 'baz'])
>>>
>>>OK, so that implies that we need to be able to index Python args as
>>>well, no?
>>>
>>>   def(&f
>>>     , array_with_size::ptr(_1, _1)
>>>                        C++ ^^  ^^ Lua/Python
>>>     , array_with_size::size(_2, _1)
>>>                         C++ ^^  ^^ Lua/Python
>>>   );
>>>
>>>or something..
>> I prefer:  array_with_size(_1, _2) <- _1
>> without the arrows it gets really hard to keep track of all the
>> placeholders and what their roles are.
>
> OK. :)

Hah!  Beaten into submission!
;->

BTW, the basic syntax idea of building the <- is Joel de Guzman's.

>>>>Did you happen to notice the discussion of runtime-polymorphic,
>>>>unified-syntax wrapping on the C++-sig?
>>>
>>>Yes I did but I'm not sure I like the idea. For instance, it means
>>>policies would have to be completely language-independent which I don't
>>> think is always possible. 
>> I recognize that problem, but I think we ought to give it more
>> thought.  I'm not sure it's precisely accurate.  I can imagine a
>> plug-in system which allows users to add language-specific
>> policies... but my primary interest in it has to do with reducing
>> compilation time.  Assembling the converter lookup logic (etc.) just
>> once instead of multiple times could be a huge benefit.
>
> My primary interest in it would be the language-independent interface,
> adding support for multiple scripting languages with the same calls
> would be great. I'd hate to give up on compile time knowledge by
> introducing a virtual call boundary though, 

I'm not sure there's much to give up here.  There are already several
layers of indirection at work in Boost.Python, in part because it's
impossible to generate an extern "C" function template.  From the
Python POV, more of the hard-core logic could be moved into the
implementation of the Python function object's extern "C"
implementation function.

IIRC Boost.Python is already way faster than SWIG (except for one
degenerate case which I know how to handle) so I don't think we'd
lose much, if anything.

> so lets think about this some more.

Yes, let's.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/