Re: [pygccxml-development] argument policies

[Roman Y. <rom...@gm...>]

On 5/4/06, Matthias Baas <ba...@ir...> wrote:
> > For example "return status as exception" arg policies could be solved i=
n
> > Python.
>
> But then it would only work on classes instantiated from Python and not
> on classes returned from wrapped C++ functions. So it's not equivalent
> to implementing the above right inside the C++ wrappers.

It is not true. I will show you an example later.

> >> For example, I have
> >> C++ methods that look like this:
> >>
> >>    void get(double*)
> >>
> >> They just return an array of a predefined size. With my current arg
> >> policies I can turn that into a Python method that takes no arguments
> >> and returns a list of floats. But meanwhile I'm also toying with the
> >> idea to provide an additional version of the method that takes a list =
as
> >> argument and that will fill that list with the return values. This wil=
l
> >> be less "Pythonic" but it's closer to the original C++ API.
> >> I don't know if it should really be the arg policy that creates the
> >> additional wrapper or if it should be done by the user. For example, I
> >> could also imagine a way where the user can "clone" a declaration and
> >> then just apply a different arg policy to the clone.
> >
> > This will never work ( reliably ). py++ assumes that code is 100% corre=
ct.
>
> I don't understand those two sentences. What exactly are you referring
> to that will never work? And which code is not correct?

Sorry. I meant that you can not clone a declaration. You can not have
in your code to
identical declarations within the same scope. So I don't know whether
this technique will
work or not.

> > Another way to solve this is to parse files, generate C++ wrapper for
> > the functions,
> > and then to parse again with generated functions wrappers.
>
> But all the information is already there after one parsing step, so why
> is it better to do another pass?

I thought about another approach, cause the way you proposed will not work.
But right now I think I have better idea. Instead of having 1
arguments policy, function
will have a list of arguments policies. module_creator.creator_t
will split it out. It will create calldef_t and calldef_wrapper_t for
every arguments policy.

> I just would have put the stuff from the experimental directory into
> "contrib/pypp_api" and the array stuff in, say, "contrib/arrayinfo"...

Please do it.

> - Matthias -


--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/