Re: [pygccxml-development] FT - open issues

[Matthias B. <ba...@ir...>]

Roman Yakovenko wrote:
> 2. Name uniqueness\resolution. For example:
>     for next C++ code
> 
>     namespace ft{
>     struct xxx_t{
>         static void get_value( int& x ){ x = 21; }
>      private:
>         ~xxx_t(){}
>      };
> 
>    Py++ generates next code
> 
>    static boost::python::object _py_get_value(  ) {
>        int x;
>        xxx_t::get_value(x);
>        return boost::python::object(x);
>    }
> 
>    Obviously if I will introduce similar class with other name, Py++
> will not generate unique name for get_value.

You're right. (On the other hand, this other class might reside in its 
own source file anyway which reduces chances for a name clash)
I'll see what I can do. I guess it shouldn't be a problem to incorporate 
the class name into the function name.

> 3. transformers index argument from 1 and not from zero. I think we
> need to discuss
>     this one more time. I don't agree with this interface. This is
> tooooo confusing.

Here's a piece of code from the Boost.Python tutorial:

def("f", f,
     return_internal_reference<1,
         with_custodian_and_ward<1, 2> >());

The numbers 1 and 2 refer to the first and second argument. So I would 
find it confusing if Py++ would do it otherwise.

Besides that, I've reserved the index 0 to represent the return value.

> 4. Base class for all transformations should be introduced.

There is one already: function_transformer_t
You may certainly derive from that class if you wish, it's just that you 
don't have to (because this class just defines/documents the interface 
and doesn't contain any actual code).

> 6. Generated code should be different. I mean we should introduce more
> convenience functions in code repository.

Right, I haven't had the time yet to incorporate all the stuff from that 
other thread. But speaking of which, I did try to find that 
boost::python::len function you were mentioning but couldn't find it 
anywhere.

- Matthias -