[C++-sig] Py++ - problem with split_module andreturn_opaque_pointer-policy

Ganssauge, Gottfried Gottfried.Ganssauge at haufe.de
Tue Sep 12 13:37:07 CEST 2006


> -----Original Message-----
> From: c++-sig-bounces at python.org 
> [mailto:c++-sig-bounces at 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 at 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 at python.org
> http://mail.python.org/mailman/listinfo/c++-sig
> 

Cheers,

Gottfried



More information about the Cplusplus-sig mailing list