Py++ - problem with split_module and return_opaque_pointer-policy
The return_value_policy<return_opaque_pointer> requires an additional macro call (BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID) in the declaration section of a module. This can be added e.g. using module_builder_t.add_declaration_code(), and it works as long as you're generating the code using write_module(). In the moment you're using "split_module" to split your output, this scheme breaks, because BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID is required in every translation unit using the opaque pointer type whose type_id is defined with that macro. Instead it is only generated into the main module. An example: test.hpp: ========= typedef struct opaque_ *opaque_pointer; opaque_pointer get_opaque(); test.py: ======== import os from pyplusplus import module_builder from pyplusplus.decl_wrappers import \ return_value_policy, \ return_opaque_pointer mb = module_builder.module_builder_t( ["test.hpp"] ) mb.add_declaration_code ("BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(opaque_)") mb.free_function (name = "get_opaque").call_policies = \ return_value_policy (return_opaque_pointer) mb.build_code_creator( module_name='test_opaque' ) mb.split_module( '.' ) When compiled with g++ -c -I/usr/include/python2.4 test_opaque*cpp this produces the following sermon: boost/python/type_id.hpp: In function `boost::python::type_info boost::python::type_id() [with T = opaque_]': boost/python/lvalue_from_pytype.hpp:23: instantiated from `boost::python::type_info boost::python::detail::extractor_type_id(T&(*)(U)) [with T = opaque_, U = boost::python::opaque_pointer_converter<opaque_*>::instance&]' boost/python/lvalue_from_pytype.hpp:88: instantiated from `boost::python::lvalue_from_pytype<Extractor, python_type>::lvalue_from_pytype() [with Extractor = boost::python::opaque_pointer_converter<opaque_*>, const PyTypeObject*python_type = ((const PyTypeObject*)(&boost::python::opaque_pointer_converter<opaque_*>::type_ object))]' boost/python/opaque_pointer_converter.hpp:116: instantiated from `void boost::python::opaque_pointer_converter<Pointer>::register_self() [with Pointer = opaque_*]' boost/python/opaque_pointer_converter.hpp:70: instantiated from `boost::python::opaque_pointer_converter<Pointer>::opaque_pointer_conver ter(const char*) [with Pointer = opaque_*]' boost/python/return_opaque_pointer.hpp:25: instantiated from `PyObject* boost::python::detail::opaque_conversion_holder<Pointer>::operator()(Poi nter) const [with Pointer = opaque_*]' boost/python/detail/invoke.hpp:75: instantiated from `PyObject* boost::python::detail::invoke(boost::python::detail::invoke_tag_< false, false>, const RC&, F&) [with RC = boost::python::detail::opaque_conversion_holder<opaque_*>, F = opaque_*(*)()]' boost/python/detail/caller.hpp:199: instantiated from `PyObject* boost::python::detail::caller_arity<0u>::impl<F, Policies, Sig>::operator()(PyObject*, PyObject*) [with F = opaque_*(*)(), Policies = boost::python::return_value_policy<boost::python::return_opaque_pointer, boost::python::default_call_policies>, Sig = boost::mpl::vector1<opaque_*>]' boost/python/object/py_function.hpp:38: instantiated from `PyObject* boost::python::objects::caller_py_function_impl<Caller>::operator()(PyOb ject*, PyObject*) [with Caller = boost::python::detail::caller<opaque_*(*)(), boost::python::return_value_policy<boost::python::return_opaque_pointer, boost::python::default_call_policies>, boost::mpl::vector1<opaque_*> >]' test_opaque_free_functions.pypp.cpp:21: instantiated from here boost/python/type_id.hpp:71: error: invalid use of undefined type `struct opaque_' test.hpp:1: error: forward declaration of `struct opaque_' Cheers, Gottfried
On 9/12/06, Ganssauge, Gottfried <Gottfried.Ganssauge@haufe.de> wrote:
The return_value_policy<return_opaque_pointer> requires an additional macro call (BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID) in the declaration section of a module. This can be added e.g. using module_builder_t.add_declaration_code(), and it works as long as you're generating the code using write_module().
In the moment you're using "split_module" to split your output, this scheme breaks, because BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID is required in every translation unit using the opaque pointer type whose type_id is defined with that macro. Instead it is only generated into the main module.
Does "every translation unit" means "in every cpp file" ? If not the quick work-around I can propose is to put this macro in some header file and to include it. The solution to your problem requires small refactoring in Py++. I will do that before next release, but it will take some time. The solution will be to add "add_declaration_code" to free function: mb = module_builder.module_builder_t( ["test.hpp"] ) get_opaque = mb.free_function (name = "get_opaque") get_opaque.add_declaration_code("BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(opaque_)") get_opaque.call_policies = return_value_policy (return_opaque_pointer) What do you think? -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/
-----Original Message----- From: c++-sig-bounces@python.org [mailto:c++-sig-bounces@python.org] On Behalf Of Roman Yakovenko Sent: Tuesday, September 12, 2006 1:15 PM To: Development of Python/C++ integration Subject: Re: [C++-sig] Py++ - problem with split_module andreturn_opaque_pointer-policy
On 9/12/06, Ganssauge, Gottfried <Gottfried.Ganssauge@haufe.de> wrote:
The return_value_policy<return_opaque_pointer> requires an additional macro call (BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID) in the declaration section of a module. This can be added e.g. using module_builder_t.add_declaration_code(), and it works as long as you're generating the code using write_module().
In the moment you're using "split_module" to split your output, this scheme breaks, because BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID is required in every translation unit using the opaque pointer type whose type_id is defined with that macro. Instead it is only generated into the main module.
Does "every translation unit" means "in every cpp file" ? Yes.
If not the quick work-around I can propose is to put this macro in some header file and to include it. :-(
The solution to your problem requires small refactoring in Py++. I will do that before next release, but it will take some time. The solution will be to add "add_declaration_code" to free function:
mb = module_builder.module_builder_t( ["test.hpp"] )
get_opaque = mb.free_function (name = "get_opaque")
get_opaque.add_declaration_code("BOOST_PYTHON_OPAQUE_SPECIALIZ ED_TYPE_ID(opaque_)") get_opaque.call_policies = return_value_policy (return_opaque_pointer)
What do you think?
Sounds not too bad, but how about member functions returning opaque pointers? What do you think about a code generator more "knowledgeable" about return_value_policy? One that could see "hey, I'm being ordered to return_opaque_pointer" and then would call that macro wherever neccessary? In the code generator it could go like: if calling_policy is return_value_policy(return_opaque_pointer): opaque_base = remove_pointer (current_decl.return_value.type) add_declaration_code ('BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(%s)' % opaque_base)
-- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ _______________________________________________ C++-sig mailing list C++-sig@python.org http://mail.python.org/mailman/listinfo/c++-sig
Cheers, Gottfried
On 9/12/06, Ganssauge, Gottfried <Gottfried.Ganssauge@haufe.de> wrote:
What do you think about a code generator more "knowledgeable" about return_value_policy? One that could see "hey, I'm being ordered to return_opaque_pointer" and then would call that macro wherever neccessary? In the code generator it could go like: if calling_policy is return_value_policy(return_opaque_pointer): opaque_base = remove_pointer (current_decl.return_value.type) add_declaration_code ('BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(%s)' % opaque_base)
This is even better solution. I will implement it and will let you know. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/
On 9/12/06, Roman Yakovenko <roman.yakovenko@gmail.com> wrote:
On 9/12/06, Ganssauge, Gottfried <Gottfried.Ganssauge@haufe.de> wrote:
What do you think about a code generator more "knowledgeable" about return_value_policy? One that could see "hey, I'm being ordered to return_opaque_pointer" and then would call that macro wherever neccessary? In the code generator it could go like: if calling_policy is return_value_policy(return_opaque_pointer): opaque_base = remove_pointer (current_decl.return_value.type) add_declaration_code ('BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(%s)' % opaque_base)
This is even better solution. I will implement it and will let you know.
Good evening. It took some time, but I finally implemented this functionality. Can you check-out the source code from svn and test it? Thanks. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/
-----Original Message----- From: c++-sig-bounces@python.org [mailto:c++-sig-bounces@python.org] On Behalf Of Roman Yakovenko Sent: Sunday, September 24, 2006 8:28 PM To: Development of Python/C++ integration Subject: Re: [C++-sig] Py++ - problem with split_moduleandreturn_opaque_pointer-policy
On 9/12/06, Roman Yakovenko <roman.yakovenko@gmail.com> wrote:
On 9/12/06, Ganssauge, Gottfried <Gottfried.Ganssauge@haufe.de> wrote:
What do you think about a code generator more "knowledgeable" about return_value_policy? One that could see "hey, I'm being ordered to return_opaque_pointer" and then would call that macro wherever neccessary? In the code generator it could go like: if calling_policy is return_value_policy(return_opaque_pointer): opaque_base = remove_pointer (current_decl.return_value.type) add_declaration_code ('BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(%s)' % opaque_base)
This is even better solution. I will implement it and will let you know.
Good evening. It took some time, but I finally implemented this functionality. Can you check-out the source code from svn and test it? Well - I did. The result still doesn't compile :-( Do I have to call something in order to trigger your change? I'm using the test case I sent in original message
Cheers, Gottfried
Thanks.
-- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ _______________________________________________ C++-sig mailing list C++-sig@python.org http://mail.python.org/mailman/listinfo/c++-sig
On 9/25/06, Ganssauge, Gottfried <Gottfried.Ganssauge@haufe.de> wrote:
What do you think about a code generator more "knowledgeable" about return_value_policy? One that could see "hey, I'm being ordered to return_opaque_pointer" and then would call that macro wherever neccessary? In the code generator it could go like: if calling_policy is return_value_policy(return_opaque_pointer): opaque_base = remove_pointer (current_decl.return_value.type) add_declaration_code ('BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(%s)' % opaque_base)
This is even better solution. I will implement it and will let you know.
Good evening. It took some time, but I finally implemented this functionality. Can you check-out the source code from svn and test it? Well - I did. The result still doesn't compile :-( Do I have to call something in order to trigger your change? I'm using the test case I sent in original message
Strange. I just commited unit test that test the code. All works as expected. Can you post the error? Also you don't have to add BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID macro Py++ will generate one. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/
-----Original Message----- From: c++-sig-bounces@python.org [mailto:c++-sig-bounces@python.org] On Behalf Of Roman Yakovenko Sent: Monday, September 25, 2006 12:21 PM To: Development of Python/C++ integration Subject: Re: [C++-sig] Py++ - problem withsplit_moduleandreturn_opaque_pointer-policy
On 9/25/06, Ganssauge, Gottfried <Gottfried.Ganssauge@haufe.de> wrote: ...
Well - I did. The result still doesn't compile :-( Do I have to call something in order to trigger your change? I'm using the test case I sent in original message
Strange. I just commited unit test that test the code. All works as expected. Can you post the error? Don't bother - it was my fault.
Also you don't have to add BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID macro To be exact: I _must_ not add ...
Py++ will generate one. Indeed. It works quite nice :-)
Thanks, Gottfried
-- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ _______________________________________________ C++-sig mailing list C++-sig@python.org http://mail.python.org/mailman/listinfo/c++-sig
participants (2)
-
Ganssauge, Gottfried -
Roman Yakovenko