Re: [pygccxml-development] Code inserters/Arg policies

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

On 8/8/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > One question: it is not clear how is registration will look like?
>
> I have added a section "Summary" that contains the full code for option
> 3 with additional comments:
>
> https://realityforge.vrsource.org/view/PyppApi/CodeInserter#Summary
>
> I have also slightly modified the code from option 3 so that now the
> default_spam() method looks the same as in the initial version (i.e. it
> doesn't need any code modifiers).

Two comments:
1.  May be I missed something, but it seems to me that registration should also
   contain Viking_Wrapper::spam, am I right?

2. In C++ arguments by reference used as: in, out, in and out. May be
   func_spam callable should take int and return int.

> > There is one more test I'd like to see: multiple inheritance.
>
> Could you please provide more details about that? Multiple inheritance
> in C++ or in Python? Who is deriving from who? And on what instance
> should the method call be made?

Sorry I was not clear, multiple inheritance in C++. py++ creates wrapper class
for every class in the hierarchy. I am sure this will work. But still,
I think it
is worse to add such test case.

>
> > mb = module_builder_t( ... )
> >
> > spam = mb.member_function( '::Viking::spam' )
> > spam.what I should write here in order to get the desired effect
>
> I think that should still be the decoration interface as already
> mentioned here:
> https://realityforge.vrsource.org/view/PyppApi/CodeInserter#Decoration

I see. What should be done with wrappers py++ generates? Do you wan to define
"default policies" ? "Default policies" does not have to be a class,
it could be just
a terminology.

> That is, there should be at least one decoration operation that allows
> me to attach "code modifier" objects to one particular function.
> At this level the user doesn't even have to know about the problem with
> non-pure virtual functions, it just works the same as with non-virtual
> functions. Knowing about the details is only necessary when you want to
> write your own "code modifiers".

I agree with the solution, but we will have to find better name. May
be "policies"
will be good enough?

> > Did you use ctypes package? If not, try to find time and to read about it
> > ( http://starship.python.net/crew/theller/ctypes/ ). I think about
> > introducing
> > fundamental data types to boost.python library or to pyplusplus and
> > teaching py++ to generate Python code.
>
> With Python 2.5 ctypes will be part of the standard Python library, so
> at least it might be worth investigating if we could re-use some code
> here. But to be able to comment on it I would need to know more details
> about what you're planning on doing...

Actually I thought about extending boost.python library with classes that have
interface similar to "fundamental types" in ctypes:

For example:

struct native_int{
    explicit native_int( int v ) : value( v ){}

   int& get_ref(){ return value; }

   const int& get_ref() const { return value; }

   int get_value(){ return value; }

private:
    int value;
};

C++:

void spam( int & ) - will be exported as is

>From Python:
import my_module
i = my_module.native_types.native_int( 23 )
my_module.spam( i )
print i.value

In my opinion, boost.python should understand that user passes native_int
and to generate an appropriate call.

If I understand right the implementation of ctypes, it works directly with
the C stack, we can do the same thing in C++.


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