Re: [pygccxml-development] Removing copy constructor

[Benoit L. <ben...@mo...>]

Roman Yakovenko wrote:
> On Tue, Apr 13, 2010 at 5:58 PM, Benoit Leveau
> <ben...@mo...> wrote:
> 
>> using your example, I indeed don't get a copy-constructor, even after
>> "complexifying" the class so it looks more like mine... this is probably
>> something tricky! I'm not sure I really have to bind that class, but I'll
>> let you know if I find where the problem was
> 
> Thanks. "copyable" is the most "fragile" part of the project. That's
> why I has so many tests for it.
>> I was thinking about something. I had a few troubles now and then using the
>> call_policies. I explain:
>> If you want to use "copy_non_const_reference" you use:
>> function.call_policies =
>> call_policies.return_value_policy(call_policies.copy_non_const_reference)
>>
>> but if you want to use return_internal_reference you use:
>> function.call_policies = call_policies.return_internal_reference()
>>
>> I had to look into call_policies.py and from time to time I forget and get
>> some errors (even sometimes py++ doesn't complain but the errors appear at
>> compilation).
>> All these policies are listed in the same section, without any mention that
>> one is a function, the others are string and need to be passed to
>> return_value_policy().
>> It might be useful to add that to the documentation, if it's not already
>> somewhere I missed.
> 
> I tried to implement the interface similar to Boost.Python library:
> 
> http://www.boost.org/doc/libs/1_42_0/libs/python/doc/tutorial/doc/html/python/functions.html#python.call_policies
> 
>     * with_custodian_and_ward: Ties lifetimes of the arguments
>     * with_custodian_and_ward_postcall: Ties lifetimes of the
> arguments and results
>     * return_internal_reference: Ties lifetime of one argument to that of result
>     * return_value_policy<T> with T one of:
>           o reference_existing_object: naive (dangerous) approach
>           o copy_const_reference: Boost.Python v1 approach
>           o copy_non_const_reference:
>           o manage_new_object: Adopt a pointer and hold the instance
> 
> where you replace "< T >" with "( T )", I hoped it will be enough to
> look at Boost.Python documentation and understand how the code (py++)
> should be written.
> 
> Will few comments in the source file fix this or we need to introduce
> some validation checks?

I don't think introducing some validation checks is necessary.
The confusing thing is that the online doc shows a different indentation 
than what you just said:

* default_call_policies
* return_value_policy
    - return_opaque_pointer
    - copy_const_reference
    - return_by_value
    - copy_non_const_reference
    - return_internal_reference <= should be at the same level as 
return_value_policy, else we think we must use return_value_policy( 
return_internal_reference )
* return self

so this would just be a matter of changing the indentation in
docs/documentation/functions/call_policies/call_policies.rest