pygccxml-development

Re: [pygccxml-development] FT - name uniqueness

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

On 10/12/06, Matthias Baas <ba...@ir...> wrote:
> 2. Your initial mail was dealing with functions that are inside the same
> scope. The above code should be no problem at all as the class name is
> incorporated into the wrapper name as well when the wrappers are free
> functions. If you have an example where this is not the case, then this
> might be a bug.

I remember that I post the example for free functions, when Py++ generates
to functions with the same signature. May be you already fixed it. I will check.

> >> The question may then rather be: who should report the error, Py++ or
> >> the compiler? I think it's desirable that Py++ notices this situation
> >> and can issue an error, but I don't think it's a good idea to mangle the
> >> name so that the code compiles but produces functions that could not be
> >> called because they are shadowed by other functions.
> >
> > Generated code should work. And it is possible to achieve this.
>
> Without that the user assigns an alias?

Yes, Py++ will do it for him.

>  How will you do that?

get_value1
get_value2
...

> If you use the same name to register two different functions that have
> the same signature then one of those functions is not accessible in
> Python. How should Boost.Python distinguish between the two?

Py++ should not generate code like this, unfortunately FT classes does
not provide
"function signature" functionality. I think this should be fixed.

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

Re: [pygccxml-development] FT - name uniqueness

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

Roman Yakovenko wrote:
> On 10/11/06, Matthias Baas <ba...@ir...> wrote:
>> Right. And as long as the alias is used for the wrapper names (which is
>> currently the case) the above problem doesn't exist.
> 
> You are wrong. Consider next case:
> 
> struct window{
> void get_size( int&, int& );
> };
> 
> struct image{
> void get_size( int&, int& );
> };
> 
> What you propose will force user always specify a function alias. 

1. I was not proposing anything at all, I was just describing the 
current situation which I think is not that bad (I'd just like to avoid 
that a "fix" will automatically produce code that compiles but that 
makes one function inaccessible. For me, this would be worse than the 
current situation).

2. Your initial mail was dealing with functions that are inside the same 
scope. The above code should be no problem at all as the class name is 
incorporated into the wrapper name as well when the wrappers are free 
functions. If you have an example where this is not the case, then this 
might be a bug.

>> The question may then rather be: who should report the error, Py++ or
>> the compiler? I think it's desirable that Py++ notices this situation
>> and can issue an error, but I don't think it's a good idea to mangle the
>> name so that the code compiles but produces functions that could not be
>> called because they are shadowed by other functions.
> 
> Generated code should work. And it is possible to achieve this. 

Without that the user assigns an alias? How will you do that?
If you use the same name to register two different functions that have 
the same signature then one of those functions is not accessible in 
Python. How should Boost.Python distinguish between the two?

- Matthias -

Re: [pygccxml-development] __str__ and op<<

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

On 10/11/06, Matthias Baas <ba...@ir...> wrote:
> Allen Bierbaum wrote:
> > Does anyone have any code that "automatically" creates a __str__
> > operator for a class if it has an ostream op<< that can write it out in C++?
>
> For the Maya bindings I manually create __str__ methods and use cdef to
> assign them to the classes (luckily I don't need such a method for every
> class). I don't remember the details but I had some problems when I
> tried to wrap the << operator directly.
>
> As to a fully automatic solution, isn't one of the problems that Py++
> doesn't take friend functions into account? (or does it meanwhile?)

I am not sure whether GCC-XML reports friendship or not. Py++ do take into
account free operators. It injects them directly into the class. Take a look on
creator_t._adopt_free_operator method.

For next release I plan to add "add_method" to the decl_wrappers.class_t.
And an algorithm that will find all functions, that could be exposed as methods.
For example:

struct data{
    X x;
    Y y;
};

std::auto_ptr< data > create();
    could be added as "init" method

void initialize( data& )
    could be added as new method
    User will be able to write in Python:
d = data();
d.initialize()


This feature + FT will make Py++ to handle C code much better than now.

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

Re: [pygccxml-development] FT - name uniqueness

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

On 10/11/06, Matthias Baas <ba...@ir...> wrote:
> Right. And as long as the alias is used for the wrapper names (which is
> currently the case) the above problem doesn't exist.

You are wrong. Consider next case:

struct window{
void get_size( int&, int& );
};

struct image{
void get_size( int&, int& );
};

What you propose will force user always specify a function alias. While in my
proposition, user will have to do this only in case he has overloaded functions
in the same scope.

> The question may then rather be: who should report the error, Py++ or
> the compiler? I think it's desirable that Py++ notices this situation
> and can issue an error, but I don't think it's a good idea to mangle the
> name so that the code compiles but produces functions that could not be
> called because they are shadowed by other functions.

Generated code should work. And it is possible to achieve this. In case we have
problems like this, it could be nice to compare function signatures
and to decide
what alias to give for the functions.

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

Re: [pygccxml-development] FT -subst_t

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

On 10/11/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> >> > I propose to delete subst_t class. Main reason:
> >> > Method substitute defines some logic, according to which this it
> >> decides how to
> >> > indent the code. This is just wrong. code_manager_t class understands
> >> > the meaning of
> >> > the variables, so it is its respocibility to indent the code. Without
> >> > subsitute method this class is pretty useless.
> >>
> >> This proposal doesn't mention how to get back the actual functionality
> >> after removing subst_t. So I take it you suggest to move the
> >> substitute() method into the code_manager_t class?
> >
> > Yes. code_manager_t class understands the variables, so it is its
> > responsibility
> > to indent them.
>
> Well, personally I don't see any advantage or benefit of doing this
> change as the resulting code will behave just the same as before

It makes the difference what class formats the code: the one that actually
understands the code, or another, which uses some tricky logic, that envolves
parsing and using regular expression.

> The implementations would be more or less equivalent.

No.

> So why spending precious time modifying
> internal code that works already? I think we've already wasted too much
> time discussing this detail anyway, so as it obviously has a much higher
> importance to you I'd simply suggest you go ahead with the modification.
> As long as the package works as before I don't mind how the internals
> are implemented.

Okey.

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

Re: [pygccxml-development] __str__ and op<<

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

Allen Bierbaum wrote:
> Does anyone have any code that "automatically" creates a __str__ 
> operator for a class if it has an ostream op<< that can write it out in C++?

For the Maya bindings I manually create __str__ methods and use cdef to 
assign them to the classes (luckily I don't need such a method for every 
class). I don't remember the details but I had some problems when I 
tried to wrap the << operator directly.

As to a fully automatic solution, isn't one of the problems that Py++ 
doesn't take friend functions into account? (or does it meanwhile?)

- Matthias -

Re: [pygccxml-development] FT -subst_t

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

Roman Yakovenko wrote:
>> > I propose to delete subst_t class. Main reason:
>> > Method substitute defines some logic, according to which this it 
>> decides how to
>> > indent the code. This is just wrong. code_manager_t class understands
>> > the meaning of
>> > the variables, so it is its respocibility to indent the code. Without
>> > subsitute method this class is pretty useless.
>>
>> This proposal doesn't mention how to get back the actual functionality
>> after removing subst_t. So I take it you suggest to move the
>> substitute() method into the code_manager_t class?
> 
> Yes. code_manager_t class understands the variables, so it is its 
> responsibility
> to indent them.

Well, personally I don't see any advantage or benefit of doing this 
change as the resulting code will behave just the same as before and as 
I said already, this is an internal and minor detail of the package that 
the user will never get in touch with anyway. The implementations would 
be more or less equivalent. So why spending precious time modifying 
internal code that works already? I think we've already wasted too much 
time discussing this detail anyway, so as it obviously has a much higher 
importance to you I'd simply suggest you go ahead with the modification. 
As long as the package works as before I don't mind how the internals 
are implemented.

- Matthias -

Re: [pygccxml-development] FT - name uniqueness

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

Roman Yakovenko wrote:
>> >> > Hi. I would like to propose solution for function name uniqueness
>> >> problems.
>> >> >
>> >> > Problem description:
>> >> >
>> >> > void do_smth( int& );
>> >> > void do_smth( int&, int& );
>> >> >
>> >> > If user will specify output_t transformer for both functions the
>> >> > generate code will
>> >> > not compile, because Py++ will generate 2 functions with the same
>> >> signature.
>> >> >
>> >> > In order to solve this problem, we have to mangle into function name
>> >> next data:
>> >> > 1. full name ( namespaces, class names )
>> >> > 2. return type information
>> >> > 3. arguments type information
>> >> > 4. template arguments type information
>> >>
>> >> Assuming that the name has been mangled, how do you invoke those two
>> >> functions from Python?
>> >
>> > I don't change the "alias" of the function, only its wrapper name.
>> > Python will see the original function name.
>>
>> Which of the above functions will be called when I do the following in
>> Python:
>>
>>    result = do_smth()
>>
>> And how can I invoke the other function?
> 
> User will provide an aliase for the functions.

Right. And as long as the alias is used for the wrapper names (which is 
currently the case) the above problem doesn't exist.
The question may then rather be: who should report the error, Py++ or 
the compiler? I think it's desirable that Py++ notices this situation 
and can issue an error, but I don't think it's a good idea to mangle the 
name so that the code compiles but produces functions that could not be 
called because they are shadowed by other functions.
In my opinion the current behavior that I will get a compile error is 
not that bad because it guarantees that such situations won't pass 
unnoticed. A mere Py++ warning would do nothing for me as I still get 
hundreds of warnings that I just can't go through right now, so I won't 
notice this warning.

- Matthias -

[pygccxml-development] __str__ and op<<

[Allen B. <al...@vr...>]

Does anyone have any code that "automatically" creates a __str__ 
operator for a class if it has an ostream op<< that can write it out in C++?

-Allen

Re: [pygccxml-development] Py++: Potentially nasty little template method problem

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

On 10/10/06, Allen Bierbaum <al...@vr...> wrote:
> Roman Yakovenko wrote:
>
> > On 10/10/06, Allen Bierbaum <al...@vr...> wrote:
> >
> >> I just read this document and although it describes what is causing Py++
> >> to generate the code I am not sure it answers the issues I am having:
> >>
> >> 1. Only the last method wrapped is able to be called from python, so why
> >> wrap the others?
> >
> >
> > I don't understand what do you mean by the first one and by the last one.
> > I am able to call all exposed methods
>
> When you have multiple methoded registered with boost.python and they
> only vary by return types, it seems that only the last one "def"'ed
> really gets used.
>
> For example:
>
>
>      { //::OSG::GeoVectorProperty::getValue
>                  typedef ::OSG::Color3f (
> ::OSG::GeoVectorProperty::*getValue_function_type )( ::OSG::UInt32 const
> ) const;
>                      GeoVectorProperty_exposer.def(
>                "getValue"
>                , getValue_function_type(
> &::OSG::GeoVectorProperty::getValue )
>                , ( ::boost::python::arg("index") ) );
>              }
>        { //::OSG::GeoVectorProperty::getValue
>                  typedef ::OSG::Vec3f (
> ::OSG::GeoVectorProperty::*getValue_function_type )( ::OSG::UInt32 const
> ) const;
>                      GeoVectorProperty_exposer.def(
>                "getValue"
>                , getValue_function_type(
> &::OSG::GeoVectorProperty::getValue )
>                , ( ::boost::python::arg("index") ) );
>              }
>
> Maybe I am wrong here, but in this situation there is no way for
> boost.python to select which method to call correct?
>
> As I understand it this is the reason for renaming the methods using the
> aliases is to handle this and allow the user to call any of the methods.

Right

> >> 3. Why do I have to change the function name to demangled name
> >
> >
> > I think that the document explain this. What you did not understand?
> > I will try to improve the document. Even in C++ you have to use
> > x.get_value< y > syntax.
>
> What I am getting at is that all that really matters is the alias.  The
> code generated by Py++ (see above) is correct except that all the
> methods are named the same thing so they overwrite each other.  I have
> found that if I just change the alias for the method then the generated
> code compiles correctly and accesses the right method.

I think you make a mistake, but it is up to you.

> >
> >> , can't I
> >> just change the alias to what I want the method to appear as and rely
> >> upon Py++ to use casts to get the correct method?
> >
> >
> > No, because you will use C style cast on unrelated types. I don't
> > know whether it will work or not. Anyway this is a wrong way to go.
>
> Don't you just end up with casts that convert the class member pointer
> to the correct signature?  It seems to work for me.

struct env_t{
    int get_value();
    template< class T>
    T get_value();
}

I think that env_t::get_value and env_t::get_value<int> have different types.
Casting from one type to another is a mistake. But I could be wrong. You'd
better ask this question on appropriate mailing list

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

Re: [pygccxml-development] Py++: Potentially nasty little template method problem

[Allen B. <al...@vr...>]

Roman Yakovenko wrote:

> On 10/10/06, Allen Bierbaum <al...@vr...> wrote:
>
>> I just read this document and although it describes what is causing Py++
>> to generate the code I am not sure it answers the issues I am having:
>>
>> 1. Only the last method wrapped is able to be called from python, so why
>> wrap the others?
>
>
> I don't understand what do you mean by the first one and by the last one.
> I am able to call all exposed methods

When you have multiple methoded registered with boost.python and they 
only vary by return types, it seems that only the last one "def"'ed 
really gets used.

For example:


     { //::OSG::GeoVectorProperty::getValue
                 typedef ::OSG::Color3f ( 
::OSG::GeoVectorProperty::*getValue_function_type )( ::OSG::UInt32 const 
) const;
                     GeoVectorProperty_exposer.def(
               "getValue"
               , getValue_function_type( 
&::OSG::GeoVectorProperty::getValue )
               , ( ::boost::python::arg("index") ) );
             }
       { //::OSG::GeoVectorProperty::getValue
                 typedef ::OSG::Vec3f ( 
::OSG::GeoVectorProperty::*getValue_function_type )( ::OSG::UInt32 const 
) const;
                     GeoVectorProperty_exposer.def(
               "getValue"
               , getValue_function_type( 
&::OSG::GeoVectorProperty::getValue )
               , ( ::boost::python::arg("index") ) );
             }

Maybe I am wrong here, but in this situation there is no way for 
boost.python to select which method to call correct?

As I understand it this is the reason for renaming the methods using the 
aliases is to handle this and allow the user to call any of the methods.

>> 2. I think I see what you are getting at in the solution section about
>> renaming the methods automatically, but this only exposes the ones that
>> are called in the header files that gccxml is compiling.
>
>
> The better way to say this: this is exposes only method that were 
> instantiated.

True.

>>  In my case
>> (and I think probably in most cases where this will come up), I want to
>> create "get_value" methods for many more types then gccxml actually
>> saw.  Is there any way to know of to force these methods to be
>> instantiated similar to what we do with class templates?
>
>
> Just use similar technique and it will work. You also can add code for 
> every
> instantiated class
>
> cls.add_declaration_code( '"get_value_x", &environment_t::get_value< x 
> >' )

This seems to have the wrong number of arguments here but I think I know 
what you are getting at.

>
>> 3. Why do I have to change the function name to demangled name
>
>
> I think that the document explain this. What you did not understand?
> I will try to improve the document. Even in C++ you have to use
> x.get_value< y > syntax.

What I am getting at is that all that really matters is the alias.  The 
code generated by Py++ (see above) is correct except that all the 
methods are named the same thing so they overwrite each other.  I have 
found that if I just change the alias for the method then the generated 
code compiles correctly and accesses the right method.

>
>> , can't I
>> just change the alias to what I want the method to appear as and rely
>> upon Py++ to use casts to get the correct method?
>
>
> No, because you will use C style cast on unrelated types. I don't
> know whether it will work or not. Anyway this is a wrong way to go.

Don't you just end up with casts that convert the class member pointer 
to the correct signature?  It seems to work for me.

>
>>  (at least with gcc 4
>> I get compiler errors trying to do the equivalent of your correct code
>> and get "&::environment_t::get_value<std::string>".
>
>
> Just committed the unit test and all works as expected. I am using
> gcc 4.0.3. What is the error you get?

I will need to give it a try and find out the exact problem I was 
having.  It very well could have been specific to my usage.

-Allen

Re: [pygccxml-development] Py++: Potentially nasty little template method problem

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

On 10/10/06, Allen Bierbaum <al...@vr...> wrote:
> I just read this document and although it describes what is causing Py++
> to generate the code I am not sure it answers the issues I am having:
>
> 1. Only the last method wrapped is able to be called from python, so why
> wrap the others?

I don't understand what do you mean by the first one and by the last one.
I am able to call all exposed methods

> 2. I think I see what you are getting at in the solution section about
> renaming the methods automatically, but this only exposes the ones that
> are called in the header files that gccxml is compiling.

The better way to say this: this is exposes only method that were instantiated.

>  In my case
> (and I think probably in most cases where this will come up), I want to
> create "get_value" methods for many more types then gccxml actually
> saw.  Is there any way to know of to force these methods to be
> instantiated similar to what we do with class templates?

Just use similar technique and it will work. You also can add code for every
instantiated class

cls.add_declaration_code( '"get_value_x", &environment_t::get_value< x >' )

> 3. Why do I have to change the function name to demangled name

I think that the document explain this. What you did not understand?
I will try to improve the document. Even in C++ you have to use
 x.get_value< y > syntax.

>, can't I
> just change the alias to what I want the method to appear as and rely
> upon Py++ to use casts to get the correct method?

No, because you will use C style cast on unrelated types. I don't
know whether it will work or not. Anyway this is a wrong way to go.

>  (at least with gcc 4
> I get compiler errors trying to do the equivalent of your correct code
> and get "&::environment_t::get_value<std::string>".

Just committed the unit test and all works as expected. I am using
gcc 4.0.3. What is the error you get?

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

Re: [pygccxml-development] Py++: Potentially nasty little template method problem

[Allen B. <al...@vr...>]

Roman Yakovenko wrote:

>On 10/10/06, Allen Bierbaum <al...@vr...> wrote:
>  
>
>>Okay, so my problem is that I am wrapping a class you can see here:
>>    
>>
>
>I just commited the answer to your question. Take a look on
>how_to.rest document,
>last question: How to deal with template on return type functions?
>
>  
>
I just read this document and although it describes what is causing Py++ 
to generate the code I am not sure it answers the issues I am having:

1. Only the last method wrapped is able to be called from python, so why 
wrap the others?

2. I think I see what you are getting at in the solution section about 
renaming the methods automatically, but this only exposes the ones that 
are called in the header files that gccxml is compiling.  In my case 
(and I think probably in most cases where this will come up), I want to 
create "get_value" methods for many more types then gccxml actually 
saw.  Is there any way to know of to force these methods to be 
instantiated similar to what we do with class templates?

3. Why do I have to change the function name to demangled name, can't I 
just change the alias to what I want the method to appear as and rely 
upon Py++ to use casts to get the correct method?  (at least with gcc 4 
I get compiler errors trying to do the equivalent of your correct code 
and get "&::environment_t::get_value<std::string>".

-Allen

>>PS. I just tried the latest svn version of Py++ on my largest project
>>and things seem to be working fine.
>>    
>>
>
>Can you provide feedback on add_properties algorithms? The
>documentation in properties.rest
> document?
>
>Also can you read and correct the documentation the project has?
>
>Thank you.
>
>  
>

Re: [pygccxml-development] Future freeze

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

On 10/10/06, Allen Bierbaum <al...@vr...> wrote:
> Roman Yakovenko wrote:
>
> > On 10/10/06, Allen Bierbaum <al...@vr...> wrote:
> >
> >> Any hints at what other things
> >> will make Py++ create wrappers?
> >
> >
> > http://svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/class_wrapper.py?view=markup
> >
> >
> > Take a look on is_wrapper_needed method
> >
> Thanks.  That is a very helpful method. :)
>
> I understand most of the reasons in there, but I don't understand any of
> the member variable reasons.  Why does a bitfield, T*, T&, or array
> member variable require a wrapper to be created?

bitfield - you can not take reference to the bit, get\set functions are needed
T*, & - you should instruct Boost.Python how to manage life time of
the variable - you
    have to suppy call policies
array - boost.python does not supoprt arrays, so there is a need to
construct instance
of the class that exposes array to Python.


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

Re: [pygccxml-development] Future freeze

[Allen B. <al...@vr...>]

Roman Yakovenko wrote:

> On 10/10/06, Allen Bierbaum <al...@vr...> wrote:
>
>> Any hints at what other things
>> will make Py++ create wrappers?
>
>
> http://svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/class_wrapper.py?view=markup 
>
>
> Take a look on is_wrapper_needed method
>
Thanks.  That is a very helpful method. :)

I understand most of the reasons in there, but I don't understand any of 
the member variable reasons.  Why does a bitfield, T*, T&, or array 
member variable require a wrapper to be created?

-Allen

Re: [pygccxml-development] Future freeze

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

On 10/10/06, Allen Bierbaum <al...@vr...> wrote:
>Any hints at what other things
> will make Py++ create wrappers?

http://svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/class_wrapper.py?view=markup

Take a look on is_wrapper_needed method

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

Re: [pygccxml-development] Future freeze

[Allen B. <al...@vr...>]

Ok.

Well, then I have a method in goodies that tries to finalize a class.  
It looks like this:

-------------------------------------
def finalize(cls, finalize_pure_virtuals=True):
   if isinstance(cls, pd.mdecl_wrapper_t):
      for x in cls:
         finalize(x)
   else:
      matcher = pd.virtuality_type_matcher( pd.VIRTUALITY_TYPES.VIRTUAL )
      if finalize_pure_virtuals:
         matcher = matcher | pd.virtuality_type_matcher( 
pd.VIRTUALITY_TYPES.PURE_VIRTUAL)
      members = cls.decls( matcher,
                           decl_type=pd.member_calldef_t,
                           allow_empty=True)
      members.set_virtuality( pd.VIRTUALITY_TYPES.NOT_VIRTUAL )
--------------------------------------

This gets rid of all the virtuals but there are still some things left 
over that make Py++ create a wrapper.  Any hints at what other things 
will make Py++ create wrappers?

-Allen

Re: [pygccxml-development] Preventing Py++ from adding pure_virtual to a method

[Allen B. <al...@vr...>]

Roman Yakovenko wrote:

> On 10/10/06, Allen Bierbaum <al...@vr...> wrote:
>
>> Is there a way I can override Py++ and tell it not to generate a
>> boost::python::pure_virtual on a member method?
>
>
> f.virtuality = declaration.VIRTUALITY_TYPES.VIRTUAL
>
>> I know that normally this would be a bad idea, but I have a case where I
>> am only dealing with derived types and for some reason when the
>> pure_virtual is there it causes all calls to that method to fail with
>> "RuntimeError: Pure virtual function called".  When I remove the
>> pure_virtual call from the bindings, everything works as expected.  Also
>> for this library this is fine because objects can only be created
>> through factory methods and the system will not allow creation of any of
>> the base classes with pure virtual methods.
>
>
> Py++ & pygccxml gives you enough rope to shoot yourself in the foot.
> :-)
>
Yes, and luckily in this case the library behind the scenes will prevent 
me from hanging myself with it. :)

Thanks,
Allen

Re: [pygccxml-development] Preventing Py++ from adding pure_virtual to a method

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

On 10/10/06, Allen Bierbaum <al...@vr...> wrote:
> Is there a way I can override Py++ and tell it not to generate a
> boost::python::pure_virtual on a member method?

f.virtuality = declaration.VIRTUALITY_TYPES.VIRTUAL

> I know that normally this would be a bad idea, but I have a case where I
> am only dealing with derived types and for some reason when the
> pure_virtual is there it causes all calls to that method to fail with
> "RuntimeError: Pure virtual function called".  When I remove the
> pure_virtual call from the bindings, everything works as expected.  Also
> for this library this is fine because objects can only be created
> through factory methods and the system will not allow creation of any of
> the base classes with pure virtual methods.

Py++ & pygccxml gives you enough rope to shoot yourself in the foot.
:-)

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

[pygccxml-development] Preventing Py++ from adding pure_virtual to a method

[Allen B. <al...@vr...>]

Is there a way I can override Py++ and tell it not to generate a 
boost::python::pure_virtual on a member method?

I know that normally this would be a bad idea, but I have a case where I 
am only dealing with derived types and for some reason when the 
pure_virtual is there it causes all calls to that method to fail with 
"RuntimeError: Pure virtual function called".  When I remove the 
pure_virtual call from the bindings, everything works as expected.  Also 
for this library this is fine because objects can only be created 
through factory methods and the system will not allow creation of any of 
the base classes with pure virtual methods.

-Allen

Re: [pygccxml-development] Future freeze

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

On 10/10/06, Allen Bierbaum <al...@vr...> wrote:
> Roman Yakovenko wrote:
>
> > On 10/10/06, Allen Bierbaum <al...@vr...> wrote:
> >
> >> Will this version of Py++ have a helper method that can completely
> >> finalize a class?
> >
> >
> > Do you mean to not create wrapper for other cases than virtual and
> > pure virtual member
> > functions? If so than the answer is not, it will not contain such
> > feature.
> >
> >
> I mean don't create a wrapper at all.

No.

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

Re: [pygccxml-development] Future freeze

[Allen B. <al...@vr...>]

Roman Yakovenko wrote:

> On 10/10/06, Allen Bierbaum <al...@vr...> wrote:
>
>> Will this version of Py++ have a helper method that can completely
>> finalize a class?
>
>
> Do you mean to not create wrapper for other cases than virtual and
> pure virtual member
> functions? If so than the answer is not, it will not contain such 
> feature.
>
>
I mean don't create a wrapper at all.

-Allen

Re: [pygccxml-development] FT - name uniqueness

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

On 10/10/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > On 10/10/06, Matthias Baas <ba...@ir...> wrote:
> >> Roman Yakovenko wrote:
> >> > Hi. I would like to propose solution for function name uniqueness
> >> problems.
> >> >
> >> > Problem description:
> >> >
> >> > void do_smth( int& );
> >> > void do_smth( int&, int& );
> >> >
> >> > If user will specify output_t transformer for both functions the
> >> > generate code will
> >> > not compile, because Py++ will generate 2 functions with the same
> >> signature.
> >> >
> >> > In order to solve this problem, we have to mangle into function name
> >> next data:
> >> > 1. full name ( namespaces, class names )
> >> > 2. return type information
> >> > 3. arguments type information
> >> > 4. template arguments type information
> >>
> >> Assuming that the name has been mangled, how do you invoke those two
> >> functions from Python?
> >
> > I don't change the "alias" of the function, only its wrapper name.
> > Python will see the original function name.
>
> Which of the above functions will be called when I do the following in
> Python:
>
>    result = do_smth()
>
> And how can I invoke the other function?

User will provide an aliase for the functions.

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

Re: [pygccxml-development] FT -subst_t

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

On 10/10/06, Matthias Baas <ba...@ir...> wrote:
> Roman Yakovenko wrote:
> > I propose to delete subst_t class. Main reason:
> > Method substitute defines some logic, according to which this it decides how to
> > indent the code. This is just wrong. code_manager_t class understands
> > the meaning of
> > the variables, so it is its respocibility to indent the code. Without
> > subsitute method this class is pretty useless.
>
> This proposal doesn't mention how to get back the actual functionality
> after removing subst_t. So I take it you suggest to move the
> substitute() method into the code_manager_t class?

Yes. code_manager_t class understands the variables, so it is its responsibility
to indent them.

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

Re: [pygccxml-development] FT - name uniqueness

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

Roman Yakovenko wrote:
> On 10/10/06, Matthias Baas <ba...@ir...> wrote:
>> Roman Yakovenko wrote:
>> > Hi. I would like to propose solution for function name uniqueness 
>> problems.
>> >
>> > Problem description:
>> >
>> > void do_smth( int& );
>> > void do_smth( int&, int& );
>> >
>> > If user will specify output_t transformer for both functions the
>> > generate code will
>> > not compile, because Py++ will generate 2 functions with the same 
>> signature.
>> >
>> > In order to solve this problem, we have to mangle into function name 
>> next data:
>> > 1. full name ( namespaces, class names )
>> > 2. return type information
>> > 3. arguments type information
>> > 4. template arguments type information
>>
>> Assuming that the name has been mangled, how do you invoke those two
>> functions from Python?
> 
> I don't change the "alias" of the function, only its wrapper name.
> Python will see the original function name.

Which of the above functions will be called when I do the following in 
Python:

   result = do_smth()

And how can I invoke the other function?

- Matthias -