[C++-sig] call policies help needed
Roman Yakovenko
roman.yakovenko at gmail.com
Wed May 24 12:06:39 CEST 2006
Hi. Please consider next case:
class A{ ... };
struct B{
B( A& a )
: a( a )
{}
A& a;
};
In order to export class B, I have to create access function for
member variable a.
A& get_a( B& b ){ return b.a };
BOOST_PYTHON_MODULE(module){
class_< A > ...;
class_< B >( "B", bp::init< A& >( )[with_custodian_and_ward<1,2>()] )
.add_property( "a", make_funtion( &get_a, ???????? ) );
}
I don't know what call policies pyplusplus, code generator, should
give for make_function
by default. Why? Because there are different use case:
1. Python code:
a = module.A()
b = module.B( a )
In this case life time of "a" is already managed by boost.python,
so the return value
policy for make_function could be "return_existing_object". I
think, that in this case
it is safe to use it.( Am I wrong ? )
2. Python code:
a = module.get_the_a_object() # returns reference to existing
object a, that was created
# from C++, life time
of this object is not managed
# by boost.python
b = module.B( a )
In this case it is unsafe to use "return_existing_object". The
safer alternatives are:
1. to use "copy_[non]_const_reference", will not work for all classes, also
this is not an expected behaviour:
b.a.s = 2
will not take effect, because b.a will return copy of a
2. to use "return_internal_reference". Here I make small
assumption, that developer
has some guaranties: object "a" will not be destroyed, if
there is at least one "b"
object.
Obviously this guarantee exists in C++ code, but C++ code does not have
garbage collector. In Python, object "b", could leave longer
then object "a".
So I am not sure about this option too.
3. "return_existing_object"
4. I am sure, I missed something.
Thoughts?
Thanks for help.
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
More information about the Cplusplus-sig
mailing list