pygccxml-development

[pygccxml-development] gccxml regression from 0.7 to 0.9?

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

Hi,

This is a pure gccxml issue, but maybe someone here can confirm it.

 Since  gccxml 0.9 (CVS), when I scan these classes:

class Foo
{
    std::string m_datum;
public:
    static int instance_count;

    Foo () : m_datum ("")
        { Foo::instance_count++; }
[...]
};

class Bar : public Foo
{
public:
    static std::string Hooray () {
        return std::string ("Hooray!");
    }
    virtual ~Bar() {}
};

Now there is no constructor declared for class Bar, even though this class
in C++ inherits the default constructor  Foo::Foo().  With gccxml 0.7 it
used to report that implicity constructor.  Is this known?  Is there any
easy workaround?

Thanks in advance.

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

Re: [pygccxml-development] gccxml regression from 0.7 to 0.9?

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

On Dec 20, 2007 1:13 PM, Gustavo Carneiro <gjc...@gm...> wrote:
> Hi,
>
> This is a pure gccxml issue, but maybe someone here can confirm it.
>
>  Since  gccxml 0.9 (CVS), when I scan these classes:
>
> class Foo
> {
>     std::string m_datum;
> public:
>     static int instance_count;
>
>     Foo () : m_datum ("")
>         { Foo::instance_count++; }
> [...]
> };
>
> class Bar : public Foo
> {
> public:
>     static std::string Hooray () {
>         return std::string ("Hooray!");
>     }
>     virtual ~Bar() {}
> };
>
> Now there is no constructor declared for class Bar, even though this class
> in C++ inherits the default constructor  Foo::Foo().  With gccxml 0.7 it
> used to report that implicity constructor.  Is this known?

Yes

>Is there any easy workaround?

No.

Now the long answer. I did some research work on new GCCXML and found
next things: http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pygccxml_dev/gccxml-0.9-upgrade/
I already discussed them with Brad, the author of GCCXML,  this is not
going to change.

Now about work around. I guess you need this for your code generator,
right? If so pygccxml contains "type traits" classes, that help you to
deal with this situation. In many cases this functionality provides
the correct answer:
http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pygccxml_dev/pygccxml/declarations/type_traits.py?revision=1169&view=markup
( search for has_* functions )

pygccxml has pretty good tests for this functionality:
http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pygccxml_dev/unittests/data/type_traits.hpp?revision=1174&view=markup

If your needs is code generation, than my advise to use this functionality.

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