pygccxml-development

Re: [pygccxml-development] Tag for Methods to bind ?

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

On Mon, Jul 7, 2008 at 9:14 PM, Ben Schleimer <bsc...@lu...> wrote:
> I had this same idea. Instead of putting the annotations inside the
> comments,
> I made Qt style macros which I prepended to my function/enum/field
> declarations.
>
> Something like
> META_CLASS() class A {
>   META_METHOD() APtr create();
>
>   // No annotations before this one so it isn't exposed
>   float * getInternals();
>
> ....
> }
>
> The macros turn into  __attribute((gccxml("META_XXX")));
> when a preprocessor flag is defined and turns into nothing otherwise.
> The cool thing is that you can have additional annotations work by
> using macro inlining... I can't find the code anymore but it did work...

You are right, this is another valid option.
Every declarations contains "attributes" property wchih gives you
access to them (
http://language-binding.net/pyplusplus/documentation/apidocs/pygccxml.declarations.declaration.declaration_t-class.html#attributes
)

This approach has speed advantage and it is less error prone.

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

Re: [pygccxml-development] Tag for Methods to bind ?

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

On Mon, Jul 7, 2008 at 3:06 PM, Damien Fagnou
<dam...@mo...> wrote:
> Hi ,
>
> we are thinking of using py++ to create binding to one of our libraries .
> this is quite a large one 100+ class . py++ look like its doing what we
> need and initial test are very promising .

:-)

> one of our idea was to be able to explicitly 'tag' the methods/class to
> export .
> I though we might use a tag in the doxygen comments . but I can't really
> see if that is possible
> there is the extract_doc scheme , would there be a way to filter class
> and methods based on doxygen docs ?

It is possible. Take a look on this file:
http://python-ogre.svn.sourceforge.net/viewvc/python-ogre/trunk/python-ogre/code_generators/common_utils/extract_documentation.py?view=markup

Python-Ogre project uses it to extract doxygen style documentation
from the Ogre3d source code and embed it into Python objects. So they
will have the documentation.

After you updated the declarations with documentation you can use it (
untested ):

mb = module_builder_t()
mb.global_ns.decls().exclude()
mb.global_ns.decls( lambda d: '/// BINDABLE' in d.documentation ).include()
//class includes everything under it, so we need to run exclude
mb.global_ns.decls( lambda d: '/// this class is not accessible from
python' in d.documentation ).exclude()


> one other way we though was to run doxygen using xml out , sparse the
> result and extract a list of class and methods from there. but the 2
> step workflow is not as nice and doxygen doesn't use the same parser  (
> I think .. )
>
> example :
>
> /// base class for particle
> /// BINDABLE
> class A
> {
>    /// creation methode
>    /// BINDABLE
>    APtr create()
>
>    /// this class is not accessible from python
>    float * getInternals();

Take a look on return_range call policy, it provides solution for such API
http://language-binding.net/pyplusplus/documentation/functions/call_policies.html#return-range

> in any case thanks a lot for py++ it look like its gonna save us a lot
> of time !

Thank you!

P.S. In Russian we say "не говори гоп пока не перепрыгнешь", I guess
the English variant is "Do not boast until you see the enemy dead".
:-)))



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

Re: [pygccxml-development] Tag for Methods to bind ?

[Ben S. <bsc...@lu...>]

I had this same idea. Instead of putting the annotations inside the
comments,
I made Qt style macros which I prepended to my function/enum/field
declarations.

Something like
META_CLASS() class A {
   META_METHOD() APtr create();

   // No annotations before this one so it isn't exposed
   float * getInternals();
 
....
}

The macros turn into  __attribute((gccxml("META_XXX")));
when a preprocessor flag is defined and turns into nothing otherwise.
The cool thing is that you can have additional annotations work by
using macro inlining... I can't find the code anymore but it did work...

Cheers
Ben
    

> -----Original Message-----
> From: pyg...@li... 
> [mailto:pyg...@li...] 
> On Behalf Of Damien Fagnou
> Sent: Monday, July 07, 2008 5:07 AM
> To: pyg...@li...
> Subject: [pygccxml-development] Tag for Methods to bind ?
> 
> Hi ,
> 
> we are thinking of using py++ to create binding to one of our 
> libraries .
> this is quite a large one 100+ class . py++ look like its 
> doing what we need and initial test are very promising .
> 
> one of our idea was to be able to explicitly 'tag' the 
> methods/class to export .
> I though we might use a tag in the doxygen comments . but I 
> can't really see if that is possible there is the extract_doc 
> scheme , would there be a way to filter class and methods 
> based on doxygen docs ?
> 
> one other way we though was to run doxygen using xml out , 
> sparse the result and extract a list of class and methods 
> from there. but the 2 step workflow is not as nice and 
> doxygen doesn't use the same parser  ( I think .. )
> 
> example :
> 
> /// base class for particle
> /// BINDABLE
> class A
> {
>     /// creation methode
>     /// BINDABLE
>     APtr create()
> 
>     /// this class is not accessible from python
>     float * getInternals();
> 
>     private :
>     A() {};
> }
>  
> in any case thanks a lot for py++ it look like its gonna save 
> us a lot of time !
> 
> Damien
> 
> 
> 
> 
> 
> --------------------------------------------------------------
> -----------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source 
> project, along with a healthy diet, reduces your potential 
> for chronic lameness and boredom. Vote Now at 
> http://www.sourceforge.net/community/cca08
> _______________________________________________
> pygccxml-development mailing list
> pyg...@li...
> https://lists.sourceforge.net/lists/listinfo/pygccxml-development
> 
> 

[pygccxml-development] Tag for Methods to bind ?

[Damien F. <dam...@mo...>]

Hi ,

we are thinking of using py++ to create binding to one of our libraries .
this is quite a large one 100+ class . py++ look like its doing what we 
need and
initial test are very promising .

one of our idea was to be able to explicitly 'tag' the methods/class to 
export .
I though we might use a tag in the doxygen comments . but I can't really 
see if that is possible
there is the extract_doc scheme , would there be a way to filter class 
and methods based on doxygen docs ?

one other way we though was to run doxygen using xml out , sparse the 
result and extract a list of class and methods from there. but the 2 
step workflow is not as nice and doxygen doesn't use the same parser  ( 
I think .. )

example :

/// base class for particle
/// BINDABLE
class A
{
    /// creation methode
    /// BINDABLE
    APtr create()

    /// this class is not accessible from python
    float * getInternals();

    private :
    A() {};
}
 
in any case thanks a lot for py++ it look like its gonna save us a lot 
of time !

Damien

Re: [pygccxml-development] problem with an array of pointers

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

On Mon, Jul 7, 2008 at 10:28 AM, Gordon Wrigley
<gor...@gm...> wrote:
> Disclaimer: I have no idea what I'm doing and C++ is not one of my strong
> skills. I'm having a problem with py++, boost, msvc and a third party
> library I need to bridge to python. I would greatly appreciate any help I
> can get with this.

:-)

> I don't have the various version information handy but I downloaded all of
> the boost/py++/msvc stuff from the relevant websites last week. After I
> installed everything I made it compile and run the quick start example
> correctly.
>
> I ran the library header through the py++ gui, grabbed the py++ code that
> generated, put it in a .py file, ran that and then copied the resulting
> files into the quick start example.
>
> The header for the library includes this snippet (details obscured to
> protect the guilty):
>
> class bob
> {
> public:
>     double      *fred[4];

This is a bug in Py++.

The code generated for "double* fred[4]" caused the compilation error.
It is not possible to generate code for "fred" without knowing
additional details. In this case Py++ has to exclude this variable
from being exposed and give some warning.

Now, how can you improve the situation:
* exclude variable by your own
* take a look on "return_range" (
http://language-binding.net/pyplusplus/documentation/functions/call_policies.html#return-range
) call policies.

HTH

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

[pygccxml-development] problem with an array of pointers

[Gordon W. <gor...@gm...>]

Disclaimer: I have no idea what I'm doing and C++ is not one of my strong
skills. I'm having a problem with py++, boost, msvc and a third party
library I need to bridge to python. I would greatly appreciate any help I
can get with this.

I don't have the various version information handy but I downloaded all of
the boost/py++/msvc stuff from the relevant websites last week. After I
installed everything I made it compile and run the quick start example
correctly.

I ran the library header through the py++ gui, grabbed the py++ code that
generated, put it in a .py file, ran that and then copied the resulting
files into the quick start example.

The header for the library includes this snippet (details obscured to
protect the guilty):

class bob
{
public:
    double      *fred[4];

Which produced these snippets in bindings.cpp

struct bob_wrapper : bob, bp::wrapper< bob > {
<snip>
    static pyplusplus::containers::static_sized::array_1_t< double *, 4>
    pyplusplus_fred_wrapper( ::bob & inst ){
        return pyplusplus::containers::static_sized::array_1_t< double *,
4>( inst.fred );
    }

BOOST_PYTHON_MODULE(pyplusplus){
    { //::bob
<snip>
        pyplusplus::containers::static_sized::register_array_1< double *, 4,
bp::return_internal_reference< > >( "__array_1_double__ptr__4" );
        { //bob::fred [variable], type=double *[4]

            typedef pyplusplus::containers::static_sized::array_1_t< double
*, 4> ( *array_wrapper_creator )( ::bob & );

            bob_exposer.add_property( "fred"
                , bp::make_function(
array_wrapper_creator(&bob_wrapper::pyplusplus_fred_wrapper)
                                    , bp::with_custodian_and_ward_postcall<
0, 1 >() ) );
        }

which seem to be responsible for this mess

C:\PROGRA~1\boost\BOOST_~1\libs\python\example\QUICKS~1>bjam.exe
--toolset=msvc
warning: Graph library does not contain optional GraphML reader.
note: to enable GraphML support, set EXPAT_INCLUDE and EXPAT_LIBPATH to the
note: directories containing the Expat headers and libraries, respectively.
warning: skipping optional Message Passing Interface (MPI) library.
note: to enable MPI support, add "using mpi ;" to user-config.jam.
note: to suppress this message, pass "--without-mpi" to bjam.
note: otherwise, you can safely ignore this message.
Building Boost.Regex with the optional Unicode/ICU support disabled.
Please refer to the Boost.Regex documentation for more information
(don't panic: this is a strictly optional feature).
...patience...
...found 1193 targets...
...updating 3 targets...
compile-c-c++ bin\msvc-9.0express\debug\threading-multi\extending.obj
extending.cpp
C:\PROGRA~1\boost\BOOST_~1\boost/python/detail/unwind_type.hpp(165) : error
C2664: 'boost::python::converter::detail::unwind_type_id_helper::result_ty
pe boost::python::detail::unwind_helper2<1>::execute<Generator,double>(U
*(__cdecl *)(void),Generator *)' : cannot convert parameter 1 from 'double
*c
onst (__cdecl *)(void)' to 'double *(__cdecl *)(void)'
        with
        [

Generator=boost::python::converter::detail::unwind_type_id_helper,
            U=double
        ]
        This conversion requires a reinterpret_cast, a C-style cast or
function-style cast

C:\PROGRA~1\boost\BOOST_~1\boost/python/converter/pytype_function.hpp(45) :
see reference to function template instantiation 'boost::python::c
onverter::detail::unwind_type_id_helper::result_type
boost::python::detail::unwind_type<boost::python::converter::detail::unwind_type_id_helper,T>(boo
st::type<T> *,Generator *)' being compiled
        with
        [
            T=double *const ,

Generator=boost::python::converter::detail::unwind_type_id_helper
        ]

C:\PROGRA~1\boost\BOOST_~1\boost/python/converter/pytype_function.hpp(67) :
see reference to function template instantiation 'boost::python::t
ype_info boost::python::converter::detail::unwind_type_id_<T>(boost::type<T>
*,boost::mpl::false_ *)' being compiled
        with
        [
            T=double *const
        ]

C:\PROGRA~1\boost\BOOST_~1\boost/python/converter/pytype_function.hpp(65) :
while compiling class template member function 'const PyTypeObject
 *boost::python::converter::expected_pytype_for_arg<T>::get_pytype(void)'
        with
        [
            T=double *const
        ]

C:\PROGRA~1\boost\BOOST_~1\boost/preprocessor/iteration/detail/local.hpp(34)
: see reference to class template instantiation 'boost::python::c
onverter::expected_pytype_for_arg<T>' being compiled
        with
        [
            T=double *const
        ]
        C:\PROGRA~1\boost\BOOST_~1\boost/python/detail/signature.hpp(76) :
while compiling class template member function 'const boost::python::detail
::signature_element *boost::python::detail::signature_arity<2>::im
pl<Sig>::elements(void)'
        with
        [
            Sig=boost::mpl::vector3<double *const
,pyplusplus::containers::static_sized::array_1_t<double *,4> &,unsigned
long>
        ]
        C:\PROGRA~1\boost\BOOST_~1\boost/python/detail/signature.hpp(58) :
see reference to class template instantiation 'boost::python::detail::signa
ture_arity<2>::impl<Sig>' being compiled
        with
        [
            Sig=boost::mpl::vector3<double *const
,pyplusplus::containers::static_sized::array_1_t<double *,4> &,unsigned
long>
        ]
        C:\PROGRA~1\boost\BOOST_~1\boost/python/detail/caller.hpp(232) : see
reference to class template instantiation 'boost::python::detail::signatu
re<Sig>' being compiled
        with
        [
            Sig=boost::mpl::vector3<double *const
,pyplusplus::containers::static_sized::array_1_t<double *,4> &,unsigned
long>
        ]
        C:\PROGRA~1\boost\BOOST_~1\boost/python/detail/caller.hpp(231) :
while compiling class template member function
'boost::python::detail::py_fun
c_sig_info boost::python::detail::caller_arity<2>::im
pl<F,Policies,Sig>::signature(void)'
        with
        [
            F=double *const (__thiscall
pyplusplus::containers::static_sized::array_1_t<double *,4>::* )(unsigned
long) const,
            Policies=boost::python::return_internal_reference<>,
            Sig=boost::mpl::vector3<double *const
,pyplusplus::containers::static_sized::array_1_t<double *,4> &,unsigned
long>
        ]
        C:\PROGRA~1\boost\BOOST_~1\boost/python/detail/caller.hpp(169) : see
reference to class template instantiation 'boost::python::detail::caller_
arity<2>::impl<F,Policies,Sig>' being compiled
        with
        [
            F=double *const (__thiscall
pyplusplus::containers::static_sized::array_1_t<double *,4>::* )(unsigned
long) const,
            Policies=boost::python::return_internal_reference<>,
            Sig=boost::mpl::vector3<double *const
,pyplusplus::containers::static_sized::array_1_t<double *,4> &,unsigned
long>
        ]
        C:\PROGRA~1\boost\BOOST_~1\boost/python/make_function.hpp(61) : see
reference to class template instantiation 'boost::python::detail::caller<F
,CallPolicies,Sig>' being compiled
        with
        [
            F=double *const (__thiscall
pyplusplus::containers::static_sized::array_1_t<double *,4>::* )(unsigned
long) const,
            CallPolicies=boost::python::return_internal_reference<>,
            Sig=boost::mpl::vector3<double *const
,pyplusplus::containers::static_sized::array_1_t<double *,4> &,unsigned
long>
        ]
        C:\PROGRA~1\boost\BOOST_~1\boost/python/make_function.hpp(146) : see
reference to function template instantiation 'boost::python::api::object
boost::python::detail::make_function_aux<F,CallPolicies,Signature,boost::mpl::int_<N>>(F,const
CallPolicies &,const Sig &,const boost::python::detail:
:keyword_range &,NumKeywords)' being compiled
        with
        [
            F=double *const (__thiscall
pyplusplus::containers::static_sized::array_1_t<double *,4>::* )(unsigned
long) const,
            CallPolicies=boost::python::return_internal_reference<>,
            Signature=boost::mpl::vector3<double *const
,pyplusplus::containers::static_sized::array_1_t<double *,4> &,unsigned
long>,
            N=1,
            Sig=boost::mpl::vector3<double *const
,pyplusplus::containers::static_sized::array_1_t<double *,4> &,unsigned
long>,
            NumKeywords=boost::mpl::int_<1>
        ]
        C:\PROGRA~1\boost\BOOST_~1\boost/python/class.hpp(544) : see
reference to function template instantiation 'boost::python::api::object
boost::p
ython::make_function<Fn,T2,T1,boost::mpl::vector3<T0,pyplusplus::containers::static_sized::array_1_t<TItemType,size>
&,unsigned long>>(F,const CallPol
icies &,const Keywords &,const Signature &)' being compiled
        with
        [
            Fn=double *const (__thiscall
pyplusplus::containers::static_sized::array_1_t<double *,4>::* )(unsigned
long) const,
            T2=boost::python::return_internal_reference<>,
            T1=boost::python::detail::keywords<1>,
            T0=double *const ,
            TItemType=double *,
            size=4,
            F=double *const (__thiscall
pyplusplus::containers::static_sized::array_1_t<double *,4>::* )(unsigned
long) const,
            CallPolicies=boost::python::return_internal_reference<>,
            Keywords=boost::python::detail::keywords<1>,
            Signature=boost::mpl::vector3<double *const
,pyplusplus::containers::static_sized::array_1_t<double *,4> &,unsigned
long>
        ]
        C:\PROGRA~1\boost\BOOST_~1\boost/python/class.hpp(259) : see
reference to function template instantiation 'void
boost::python::class_<W>::def_
impl<pyplusplus::containers::static_sized::array_1_t<TItemType,size>,Fn,boost::python::detail::def_helper<T1,T2>>(T
*,const char *,Fn,const Helper &,.
..)' being compiled
        with
        [
            W=wrapper_t,
            TItemType=double *,
            size=4,
            Fn=double *const (__thiscall
pyplusplus::containers::static_sized::array_1_t<double *,4>::* )(unsigned
long) const,
            T1=boost::python::detail::keywords<1>,
            T2=boost::python::return_internal_reference<>,
            T=pyplusplus::containers::static_sized::array_1_t<double *,4>,

Helper=boost::python::detail::def_helper<boost::python::detail::keywords<1>,boost::python::return_internal_reference<>>
        ]
        c:\program
files\boost\boost_1_35_0\libs\python\example\quickstart\__array_1.pypp.hpp(164)
: see reference to function template instantiation
'boost::python::class_<W> &boost::python::class_<W>::def<double*const
(__thiscall
pyplusplus::containers::static_sized::array_1_t<TItemType,size>::* )
(unsigned long)
const,boost::python::detail::keywords<1>,boost::python::return_internal_reference<>>(const
char *,Fn,const A1 &,const A2 &)' being com
piled
        with
        [
            W=wrapper_t,
            TItemType=double *,
            size=4,
            Fn=double *const (__thiscall
pyplusplus::containers::static_sized::array_1_t<double *,4>::* )(unsigned
long) const,
            A1=boost::python::detail::keywords<1>,
            A2=boost::python::return_internal_reference<>
        ]
        c:\program
files\boost\boost_1_35_0\libs\python\example\quickstart\__array_1.pypp.hpp(157)
: while compiling class template member function 'p
yplusplus::containers::static_sized::register_array_1<TItemType,size,CallPolicies>::register_array_1(const
char *)'
        with
        [
            TItemType=double *,
            size=4,
            CallPolicies=boost::python::return_internal_reference<>
        ]
        extending.cpp(100) : see reference to class template instantiation
'pyplusplus::containers::static_sized::register_array_1<TItemType,size,Call
Policies>' being compiled
        with
        [
            TItemType=double *,
            size=4,
            CallPolicies=boost::python::return_internal_reference<>
        ]

    call "C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86
>nul
cl /Zm800 -nologo
@"bin\msvc-9.0express\debug\threading-multi\extending.obj.rsp"

...failed compile-c-c++
bin\msvc-9.0express\debug\threading-multi\extending.obj...
...removing bin\msvc-9.0express\debug\threading-multi\extending.obj
...skipped <pbin\msvc-9.0express\debug\threading-multi>extending.pyd for
lack of <pbin\msvc-9.0express\debug\threading-multi>extending.obj...
...skipped <pbin\msvc-9.0express\debug\threading-multi>extending.lib for
lack of <pbin\msvc-9.0express\debug\threading-multi>extending.obj...
...failed updating 1 target...
...skipped 2 targets...



The C++ code involved in most of that template stuff is well beyond my
understanding and after a half day of digging through it I have no idea what
is going wrong.

Re: [pygccxml-development] type_traits.has_public_destructor problem

[Gustavo C. <gjc...@gm...>]

2008/7/6 Roman Yakovenko <rom...@gm...>:

> On Sun, Jul 6, 2008 at 6:07 PM, Gustavo Carneiro <gjc...@gm...>
> wrote:
> > When parsing a simple class like:
> >
> > /**
> >  * \brief a 3d cartesian position vector
> >  *
> >  * Unit is meters.
> >  */
> > class Vector
> > {
> > public:
> >   /**
> >    * \param _x x coordinate of vector vector
> >    * \param _y y coordinate of vector vector
> >    * \param _z z coordinate of vector vector
> >    *
> >    * Create vector vector (_x, _y, _z)
> >    */
> >   Vector (double _x, double _y, double _z);
> >   /**
> >    * Create vector vector (0.0, 0.0, 0.0)
> >    */
> >   Vector ();
> >   /**
> >    * x coordinate of vector vector
> >    */
> >   double x;
> >   /**
> >    * y coordinate of vector vector
> >    */
> >   double y;
> >   /**
> >    * z coordinate of vector vector
> >    */
> >   double z;
> > };
> >
> > pygccxml.declarations.type_traits.has_public_destructor is returning
> False.
> > The class has an implicit public destructor, so pygccxml is wrong
> (0.9.5).
> >
> > In my code I am working around this problem like this:
> >
> > +    def _has_public_destructor(self, cls):
> > +        for member in cls.get_members():
> > +            if isinstance(member, calldef.destructor_t):
> > +                if member.access_type != 'public':
> > +                    return False
> > +        return True
> >
> > Regards.
>
> Thanks. Latest CVS version of GCCXML dumps artificial declarations. It
> is the only way to reliably find-out whether a class has public
> destructor or not.
>
> For example, next use case is not covered by the posted code:
>
> struct XXX{
>
> private:
>
> virtual ~XXX(){}
>
> };
>
>
>
> struct YYY : public XXX{
>
> };


I see.  I think I can always modify my code; it's just a matter to recursing
into base classes.  But I'm too lazy, some other day :P


>
>
>
>
> /*void do_smth(){
>
>    YYY y;
>
> }
>
> */
>
>
> SVN version of pygccxml was updated.
>
> I suggest you to switch to the latest versions


Last time I checked, I got numerous cases of implicit constructors not being
reported.  It might have been that I was using an old GCCXML CVS (0.9)
version and pygccxml expecting a new CVS snapshot, but I had no time to
test.

Thanks.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

Re: [pygccxml-development] type_traits.has_public_destructor problem

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

On Sun, Jul 6, 2008 at 6:07 PM, Gustavo Carneiro <gjc...@gm...> wrote:
> When parsing a simple class like:
>
> /**
>  * \brief a 3d cartesian position vector
>  *
>  * Unit is meters.
>  */
> class Vector
> {
> public:
>   /**
>    * \param _x x coordinate of vector vector
>    * \param _y y coordinate of vector vector
>    * \param _z z coordinate of vector vector
>    *
>    * Create vector vector (_x, _y, _z)
>    */
>   Vector (double _x, double _y, double _z);
>   /**
>    * Create vector vector (0.0, 0.0, 0.0)
>    */
>   Vector ();
>   /**
>    * x coordinate of vector vector
>    */
>   double x;
>   /**
>    * y coordinate of vector vector
>    */
>   double y;
>   /**
>    * z coordinate of vector vector
>    */
>   double z;
> };
>
> pygccxml.declarations.type_traits.has_public_destructor is returning False.
> The class has an implicit public destructor, so pygccxml is wrong (0.9.5).
>
> In my code I am working around this problem like this:
>
> +    def _has_public_destructor(self, cls):
> +        for member in cls.get_members():
> +            if isinstance(member, calldef.destructor_t):
> +                if member.access_type != 'public':
> +                    return False
> +        return True
>
> Regards.

Thanks. Latest CVS version of GCCXML dumps artificial declarations. It
is the only way to reliably find-out whether a class has public
destructor or not.

For example, next use case is not covered by the posted code:

struct XXX{

private:

virtual ~XXX(){}

};



struct YYY : public XXX{

};



/*void do_smth(){

    YYY y;

}

*/


SVN version of pygccxml was updated.

I suggest you to switch to the latest versions

P.S. If nothing wrong happens, I will start working on next release - 1.0


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

[pygccxml-development] type_traits.has_public_destructor problem

[Gustavo C. <gjc...@gm...>]

When parsing a simple class like:

/**
 * \brief a 3d cartesian position vector
 *
 * Unit is meters.
 */
class Vector
{
public:
  /**
   * \param _x x coordinate of vector vector
   * \param _y y coordinate of vector vector
   * \param _z z coordinate of vector vector
   *
   * Create vector vector (_x, _y, _z)
   */
  Vector (double _x, double _y, double _z);
  /**
   * Create vector vector (0.0, 0.0, 0.0)
   */
  Vector ();
  /**
   * x coordinate of vector vector
   */
  double x;
  /**
   * y coordinate of vector vector
   */
  double y;
  /**
   * z coordinate of vector vector
   */
  double z;
};

pygccxml.declarations.type_traits.has_public_destructor is returning False.
The class has an implicit public destructor, so pygccxml is wrong (0.9.5).

In my code I am working around this problem like this:

+    def _has_public_destructor(self, cls):
+        for member in cls.get_members():
+            if isinstance(member, calldef.destructor_t):
+                if member.access_type != 'public':
+                    return False
+        return True

Regards.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

Re: [pygccxml-development] remove_const changes underlying base type decl_string

[Gustavo C. <gjc...@gm...>]

2008/6/30 Roman Yakovenko <rom...@gm...>:

> On Mon, Jun 30, 2008 at 3:11 PM, Gustavo Carneiro <gjc...@gm...>
> wrote:
> > I don't actually _need_ to remove consts from typedefs, only from the
> outer
> > type.
>
> I am not sure you are right. Consider next use case:
>
> struct item_t{};
>
> typedef const item_t c_item_t;
>
> struct value_t{
>    c_item_t v;
> };
>
> Obviously, in this case you have to find out whether the "v" is const
> or not, and generate different code.


I see.

I think you're right, but that typedef is kind of evil anyway, and I would
rather deal with corner cases as they appear, particularly since some corner
cases often are theoretical and never manifest themselves in real life.


>
>
> I guess you are talking about some specific use case, which is not this.


>
> > Anyway, I copy-pasted those functions into pybindgen and patched them to
> do
> > what I need, so all is fine now.
>
> :-(. I will see what I can do.


Sorry. :P

If I get into trouble with my simplification, I'll help.  Until then...

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

Re: [pygccxml-development] remove_const changes underlying base type decl_string

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

On Mon, Jun 30, 2008 at 3:11 PM, Gustavo Carneiro <gjc...@gm...> wrote:
> I don't actually _need_ to remove consts from typedefs, only from the outer
> type.

I am not sure you are right. Consider next use case:

struct item_t{};

typedef const item_t c_item_t;

struct value_t{
    c_item_t v;
};

Obviously, in this case you have to find out whether the "v" is const
or not, and generate different code.

I guess you are talking about some specific use case, which is not this.

> Anyway, I copy-pasted those functions into pybindgen and patched them to do
> what I need, so all is fine now.

:-(. I will see what I can do.

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

Re: [pygccxml-development] remove_const changes underlying base type decl_string

[Gustavo C. <gjc...@gm...>]

2008/6/30 Roman Yakovenko <rom...@gm...>:

> On Sun, Jun 29, 2008 at 11:57 PM, Gustavo Carneiro <gjc...@gm...>
> wrote:
> > What I did was the obvious thing.  Removed the remove_alias call, and it
> now
> > works perfectly for me :-)
> >
> > I honestly don't understand why remove_alias is needed here :-/
>
> typedef const XYZ CXYZ;
>
> remove_const( CXYZ )





>
>
> will not work in such case and obviously you have to take into account
> few levels of "typedef"'s


I don't actually _need_ to remove consts from typedefs, only from the outer
type.

Anyway, I copy-pasted those functions into pybindgen and patched them to do
what I need, so all is fine now.

Thanks anyway.



>
>
> >
> > Index: pygccxml/declarations/type_traits.py
> > ===================================================================
> > --- pygccxml/declarations/type_traits.py    (revision 1362)
> > +++ pygccxml/declarations/type_traits.py    (working copy)
> > @@ -171,7 +171,8 @@
> >
> >      If type is not pointer type, it will be returned as is.
> >      """
> > -    nake_type = remove_alias( type )
> > +    #nake_type = remove_alias( type )
> > +    nake_type = type
> >      if not is_pointer( nake_type ):
> >          return type
> >      elif isinstance( nake_type, cpptypes.volatile_t ) and isinstance(
> > nake_type.base, cpptypes.pointer_t ):
> > @@ -219,7 +220,8 @@
> >
> >      If type is not reference type, it will be returned as is.
> >      """
> > -    nake_type = remove_alias( type )
> > +    #nake_type = remove_alias( type )
> > +    nake_type = type
> >      if not is_reference( nake_type ):
> >          return type
> >      else:
> > @@ -236,7 +238,8 @@
> >      If type is not const type, it will be returned as is
> >      """
> >
> > -    nake_type = remove_alias( type )
> > +    #nake_type = remove_alias( type )
> > +    nake_type = type
> >      if not is_const( nake_type ):
> >          return type
> >      else:
> >
> >
> >>
> >> --
> >> Roman Yakovenko
> >> C++ Python language binding
> >> http://www.language-binding.net/
> >
> >
> >
> > --
> > Gustavo J. A. M. Carneiro
> > INESC Porto, Telecommunications and Multimedia Unit
> > "The universe is always one step beyond logic." -- Frank Herbert
>
>
>
> --
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
>



-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

Re: [pygccxml-development] remove_const changes underlying base type decl_string

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

On Sun, Jun 29, 2008 at 11:57 PM, Gustavo Carneiro <gjc...@gm...> wrote:
> What I did was the obvious thing.  Removed the remove_alias call, and it now
> works perfectly for me :-)
>
> I honestly don't understand why remove_alias is needed here :-/

typedef const XYZ CXYZ;

remove_const( CXYZ )

will not work in such case and obviously you have to take into account
few levels of "typedef"'s

>
> Index: pygccxml/declarations/type_traits.py
> ===================================================================
> --- pygccxml/declarations/type_traits.py    (revision 1362)
> +++ pygccxml/declarations/type_traits.py    (working copy)
> @@ -171,7 +171,8 @@
>
>      If type is not pointer type, it will be returned as is.
>      """
> -    nake_type = remove_alias( type )
> +    #nake_type = remove_alias( type )
> +    nake_type = type
>      if not is_pointer( nake_type ):
>          return type
>      elif isinstance( nake_type, cpptypes.volatile_t ) and isinstance(
> nake_type.base, cpptypes.pointer_t ):
> @@ -219,7 +220,8 @@
>
>      If type is not reference type, it will be returned as is.
>      """
> -    nake_type = remove_alias( type )
> +    #nake_type = remove_alias( type )
> +    nake_type = type
>      if not is_reference( nake_type ):
>          return type
>      else:
> @@ -236,7 +238,8 @@
>      If type is not const type, it will be returned as is
>      """
>
> -    nake_type = remove_alias( type )
> +    #nake_type = remove_alias( type )
> +    nake_type = type
>      if not is_const( nake_type ):
>          return type
>      else:
>
>
>>
>> --
>> Roman Yakovenko
>> C++ Python language binding
>> http://www.language-binding.net/
>
>
>
> --
> Gustavo J. A. M. Carneiro
> INESC Porto, Telecommunications and Multimedia Unit
> "The universe is always one step beyond logic." -- Frank Herbert



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

Re: [pygccxml-development] remove_const changes underlying base type decl_string

[Gustavo C. <gjc...@gm...>]

2008/6/29 Roman Yakovenko <rom...@gm...>:

> On Sun, Jun 29, 2008 at 7:03 PM, Gustavo Carneiro <gjc...@gm...>
> wrote:
> > I have a function[1] that extracts properties from a type, using
> > pygccxml.declarations.type_traits
> >
> > For a simple type, it does nothing, and the type name is unchanged.  All
> is
> > well here:
> >
> > ***** type traits for '::uint64_t'
> > *** > return  ('uint64_t', False, 0, False)
> >
> >
> > In the following case, I call type_traits.remove_const and
> > type_traits.remove_reference, and the resulting type then appears
> different:
> >
> > ***** type traits for '::uint64_t const &'
> > *** > return  ('long unsigned int', True, 0, True)
> >
> > Yes, I know that in this system "long unsigned int" is the same as
> > uint64_t.  But I would rather work with uint64_t, due to LLP/LP platform
> > differences.
> >
> > Any hints on how to work around this?
>
> Yes. You can improve the function. The first thing the current
> implementation does - it removes "typedef"'s, it simplifies a lot.
> Almost all functions in type_traits implemented this way.
>
> I am a little bit busy these days, if you can wait, I will take a look
> on it. If not the patch is welcome.


What I did was the obvious thing.  Removed the remove_alias call, and it now
works perfectly for me :-)

I honestly don't understand why remove_alias is needed here :-/


Index: pygccxml/declarations/type_traits.py
===================================================================
--- pygccxml/declarations/type_traits.py    (revision 1362)
+++ pygccxml/declarations/type_traits.py    (working copy)
@@ -171,7 +171,8 @@

     If type is not pointer type, it will be returned as is.
     """
-    nake_type = remove_alias( type )
+    #nake_type = remove_alias( type )
+    nake_type = type
     if not is_pointer( nake_type ):
         return type
     elif isinstance( nake_type, cpptypes.volatile_t ) and isinstance(
nake_type.base, cpptypes.pointer_t ):
@@ -219,7 +220,8 @@

     If type is not reference type, it will be returned as is.
     """
-    nake_type = remove_alias( type )
+    #nake_type = remove_alias( type )
+    nake_type = type
     if not is_reference( nake_type ):
         return type
     else:
@@ -236,7 +238,8 @@
     If type is not const type, it will be returned as is
     """

-    nake_type = remove_alias( type )
+    #nake_type = remove_alias( type )
+    nake_type = type
     if not is_const( nake_type ):
         return type
     else:



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



-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

Re: [pygccxml-development] remove_const changes underlying base type decl_string

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

On Sun, Jun 29, 2008 at 7:03 PM, Gustavo Carneiro <gjc...@gm...> wrote:
> I have a function[1] that extracts properties from a type, using
> pygccxml.declarations.type_traits
>
> For a simple type, it does nothing, and the type name is unchanged.  All is
> well here:
>
> ***** type traits for '::uint64_t'
> *** > return  ('uint64_t', False, 0, False)
>
>
> In the following case, I call type_traits.remove_const and
> type_traits.remove_reference, and the resulting type then appears different:
>
> ***** type traits for '::uint64_t const &'
> *** > return  ('long unsigned int', True, 0, True)
>
> Yes, I know that in this system "long unsigned int" is the same as
> uint64_t.  But I would rather work with uint64_t, due to LLP/LP platform
> differences.
>
> Any hints on how to work around this?

Yes. You can improve the function. The first thing the current
implementation does - it removes "typedef"'s, it simplifies a lot.
Almost all functions in type_traits implemented this way.

I am a little bit busy these days, if you can wait, I will take a look
on it. If not the patch is welcome.

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

[pygccxml-development] remove_const changes underlying base type decl_string

[Gustavo C. <gjc...@gm...>]

I have a function[1] that extracts properties from a type, using
pygccxml.declarations.type_traits

For a simple type, it does nothing, and the type name is unchanged.  All is
well here:

***** type traits for '::uint64_t'
*** > return  ('uint64_t', False, 0, False)


In the following case, I call type_traits.remove_const and
type_traits.remove_reference, and the resulting type then appears different:

***** type traits for '::uint64_t const &'
*** > return  ('long unsigned int', True, 0, True)

Yes, I know that in this system "long unsigned int" is the same as
uint64_t.  But I would rather work with uint64_t, due to LLP/LP platform
differences.

Any hints on how to work around this?

[1]
http://bazaar.launchpad.net/~gjc/pybindgen/trunk/annotate/gjc%40gnome.org-20080629154751-9lgrks1m411ssn8f?file_id=gccxmlparser.py-20071117182614-93x4j7mcuw0eq1q6-1#L135
-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert

[pygccxml-development] SVN changes

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

Hi all.

Recently I made few changes in pygccxml and Py++. The CVS version of
GCCXML started to dump artificial declarations ( compiler generated
constructors and operator= ) once again. So, I update both project to
work nice with them.

Also the project have pretty good unit tests and all Py++ tests
passed, I ask you to test these changes and report any problems.

If no issues will be found, than I will start working on next release 1.0.

As always comments, bugs and help are always welcome.

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

Re: [pygccxml-development] Handling of enum value as default for parameter

[Patrick H. <pat...@pr...>]

On Jun 25, 2008, at 12:42 PM, Roman Yakovenko wrote:

> On Wed, Jun 25, 2008 at 7:35 PM, Patrick Hartling
> <pat...@pr...> wrote:
>> I have run into a case where Py++ is generating C++ code that does  
>> not
>> compile, and I am trying to determine if the problem lies with GCC- 
>> XML or
>> Py++. Code demonstrating what I am working with is attached. What  
>> happens is
>> that Py++ creates code for Y::setValue() similar to the following:
>>
>> Y_exposer.def("setValue", &Y::setValue, (bp::arg("v") = (int)(V1)));
>>
>> The use of X::V1 requires scoping in order to compile, but this is  
>> not
>> happening. This is occurring with GCC-XML built from CVS HEAD  
>> sources as of
>> yesterday and Py++ and PyGCCXML r1348. The relevant XML is shown  
>> below:
>>
>> <Method id="_151" name="setValue" returns="_134" context="_124"
>>         access="public" mangled="_ZN1Y8setValueEi"
>>         demangled="Y::setValue(int)" location="f1:10"
>>         file="f1" line="10" extern="1">
>>   <Argument name="v" type="_129" location="f1:10" file="f1"
>>             line="10" default="V1"/>
>> </Method>
>>
>> Should Py++ be resolving the scope of X::V1, or should GCC-XML do  
>> that up
>> front?
>
> In general, there is a problem with default values. GCCXML is not able
> to dump a C++ expression and in many cases it dumps some garbage. For
> example take a look on next page:
>
> http://language-binding.net/pygccxml/upgrade_issues.html#free-and-member-function-default-arguments
>
> This link also suggest you simple work around. It is suitable, if you
> have only few functions. Take a look on this page
> http://language-binding.net/pyplusplus/documentation/functions/default_args.html
> for more options supported by Py++.


That is very helpful. Thank you for the pointers.

  -Patrick


--
Patrick L. Hartling
Senior Software Engineer, Priority 5
http://www.priority5.com/

Re: [pygccxml-development] Handling of enum value as default for parameter

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

On Wed, Jun 25, 2008 at 7:35 PM, Patrick Hartling
<pat...@pr...> wrote:
> I have run into a case where Py++ is generating C++ code that does not
> compile, and I am trying to determine if the problem lies with GCC-XML or
> Py++. Code demonstrating what I am working with is attached. What happens is
> that Py++ creates code for Y::setValue() similar to the following:
>
> Y_exposer.def("setValue", &Y::setValue, (bp::arg("v") = (int)(V1)));
>
> The use of X::V1 requires scoping in order to compile, but this is not
> happening. This is occurring with GCC-XML built from CVS HEAD sources as of
> yesterday and Py++ and PyGCCXML r1348. The relevant XML is shown below:
>
>  <Method id="_151" name="setValue" returns="_134" context="_124"
>          access="public" mangled="_ZN1Y8setValueEi"
>          demangled="Y::setValue(int)" location="f1:10"
>          file="f1" line="10" extern="1">
>    <Argument name="v" type="_129" location="f1:10" file="f1"
>              line="10" default="V1"/>
>  </Method>
>
> Should Py++ be resolving the scope of X::V1, or should GCC-XML do that up
> front?

In general, there is a problem with default values. GCCXML is not able
to dump a C++ expression and in many cases it dumps some garbage. For
example take a look on next page:

http://language-binding.net/pygccxml/upgrade_issues.html#free-and-member-function-default-arguments

This link also suggest you simple work around. It is suitable, if you
have only few functions. Take a look on this page
http://language-binding.net/pyplusplus/documentation/functions/default_args.html
for more options supported by Py++.

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

[pygccxml-development] Handling of enum value as default for parameter

[Patrick H. <pat...@pr...>]

I have run into a case where Py++ is generating C++ code that does not  
compile, and I am trying to determine if the problem lies with GCC-XML  
or Py++. Code demonstrating what I am working with is attached. What  
happens is that Py++ creates code for Y::setValue() similar to the  
following:

Y_exposer.def("setValue", &Y::setValue, (bp::arg("v") = (int)(V1)));

The use of X::V1 requires scoping in order to compile, but this is not  
happening. This is occurring with GCC-XML built from CVS HEAD sources  
as of yesterday and Py++ and PyGCCXML r1348. The relevant XML is shown  
below:

   <Method id="_151" name="setValue" returns="_134" context="_124"
           access="public" mangled="_ZN1Y8setValueEi"
           demangled="Y::setValue(int)" location="f1:10"
           file="f1" line="10" extern="1">
     <Argument name="v" type="_129" location="f1:10" file="f1"
               line="10" default="V1"/>
   </Method>

Should Py++ be resolving the scope of X::V1, or should GCC-XML do that  
up front?

  -Patrick


--
Patrick L. Hartling
Senior Software Engineer, Priority 5
http://www.priority5.com/

Re: [pygccxml-development] Iteration over py++ generated maps and vectors

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

On Tue, Jun 24, 2008 at 11:06 AM, Vincent Ferries
<vin...@gm...> wrote:
> Yes, the function getNodes is a member function.
>
> Here is a little portion of the source code :
>
> namespace postLib {
>   namespace nastran {
>      class dataBase : public generic::dataBase {
>
>         private :
>            std::map<int,node> nodes ;
>
>         public :
>            dataBase(void) ;
>            ~dataBase(void) ;
>
>         // Accessing "model" member data :
>            std::map<int,node> & getNodes(void) ;
>
>      } ; // class dataBase
>   } // namespace nastran
> } // namespace postLib
>
> I cleaned all that wasn't necessary.
> After getting the node objects from the getNodes function, I need to
> recover them one by one in the map and use them in other functions, be
> able to call their methods too.
> According to me, these items are supposed to live as long as the
> dataBase is exploited.

In this case you use the right call policy  - return_internal_reference

I suggest you to read this document
http://www.boost.org/doc/libs/1_35_0/libs/python/doc/v2/indexing.html
, which explains how to use "built-in" indexing suite

HTH

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

[pygccxml-development] Re : Re : Re : Re : Re : Re : Re : Iteration over py++ generated maps and vectors

[Vincent F. <vin...@gm...>]

Yes, the function getNodes is a member function.

Here is a little portion of the source code :

namespace postLib {
   namespace nastran {
      class dataBase : public generic::dataBase {

         private :
            std::map<int,node> nodes ;

         public :
            dataBase(void) ;
            ~dataBase(void) ;

         // Accessing "model" member data :
            std::map<int,node> & getNodes(void) ;

      } ; // class dataBase
   } // namespace nastran
} // namespace postLib

I cleaned all that wasn't necessary.
After getting the node objects from the getNodes function, I need to
recover them one by one in the map and use them in other functions, be
able to call their methods too.
According to me, these items are supposed to live as long as the
dataBase is exploited.

>Sorry, I was pretty busy.
No problem, you are very reactive, that's a pleasure!

2008/6/24, Roman Yakovenko <rom...@gm...>:
> On Tue, Jun 24, 2008 at 10:14 AM, Vincent Ferries
> <vin...@gm...> wrote:
>> Absolutely no idea? :S
>
> Sorry, I was pretty busy.
>
>
>
> --
> Roman Yakovenko
> C++ Python language binding
> http://www.language-binding.net/
>

Re: [pygccxml-development] Re : Re : Re : Re : Re : Re : Iteration over py++ generated maps and vectors

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

On Tue, Jun 24, 2008 at 10:14 AM, Vincent Ferries
<vin...@gm...> wrote:
> Absolutely no idea? :S

Sorry, I was pretty busy.



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

Re: [pygccxml-development] Re : Re : Re : Re : Re : Iteration over py++ generated maps and vectors

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

On Fri, Jun 20, 2008 at 10:16 AM, Vincent Ferries
<vin...@gm...> wrote:
> More precisions again, I'm mapping the following function :
>
> std::map<int,node> & getNodes(void) ;
>
> I specify the call policy like that :
>
> nastranDb.member_function('getNodes').call_policies =
> call_policies.return_value_policy(call_policies.reference_existing_object)
>
> Is this the good way to do?

I don't know. In order to answer this question I need to see code - I
need to know what is the lifetime of the returned value.

It is also important to know whether getNodes function is member function or not

> Is there a possibility to directly get Python lists, or tuples etc?

No, you will have to write wrappers.

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

[pygccxml-development] Re : Re : Re : Re : Re : Re : Iteration over py++ generated maps and vectors

[Vincent F. <vin...@gm...>]

Absolutely no idea? :S