pygccxml-development

[pygccxml-development] compiler generated declarations?

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

I have been trying latest gccxml and pygccxml trunk with pybindgen, and am
finding something new that is happening:

/home/gjc/projects/pybindgen/trunk/tests/foo.h:193: AnnotationsWarning:
Annotation 'automatic_type_narrowing=True' not used (used in
SomeObject::NestedClass &
SomeObject::NestedClass::operator=(SomeObject::NestedClass const & arg0)
[member operator])

This operator= method is generated by the compiler or pygccxml, yet it
appears to be a real declaration with a physical location.  As a side
effect, pybindgen will look for annotation comments and complain when the
found annotations cannot be used.

Is there any way to distinguish between real definitions and synthetic ones?

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] compiler generated declarations?

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

On Wed, Aug 27, 2008 at 3:04 PM, Gustavo Carneiro <gjc...@gm...> wrote:
> I have been trying latest gccxml and pygccxml trunk with pybindgen, and am
> finding something new that is happening:
>
> /home/gjc/projects/pybindgen/trunk/tests/foo.h:193: AnnotationsWarning:
> Annotation 'automatic_type_narrowing=True' not used (used in
> SomeObject::NestedClass &
> SomeObject::NestedClass::operator=(SomeObject::NestedClass const & arg0)
> [member operator])
>
> This operator= method is generated by the compiler or pygccxml, yet it
> appears to be a real declaration with a physical location.  As a side
> effect, pybindgen will look for annotation comments and complain when the
> found annotations cannot be used.
>
> Is there any way to distinguish between real definitions and synthetic ones?

You are looking for declarations.is_artificial property

http://language-binding.net/pygccxml/apidocs/pygccxml.declarations.declaration.declaration_t-class.html#is_artificial

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

Re: [pygccxml-development] compiler generated declarations?

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

2008/8/27 Roman Yakovenko <rom...@gm...>

> On Wed, Aug 27, 2008 at 3:04 PM, Gustavo Carneiro <gjc...@gm...>
> wrote:
> > I have been trying latest gccxml and pygccxml trunk with pybindgen, and
> am
> > finding something new that is happening:
> >
> > /home/gjc/projects/pybindgen/trunk/tests/foo.h:193: AnnotationsWarning:
> > Annotation 'automatic_type_narrowing=True' not used (used in
> > SomeObject::NestedClass &
> > SomeObject::NestedClass::operator=(SomeObject::NestedClass const & arg0)
> > [member operator])
> >
> > This operator= method is generated by the compiler or pygccxml, yet it
> > appears to be a real declaration with a physical location.  As a side
> > effect, pybindgen will look for annotation comments and complain when the
> > found annotations cannot be used.
> >
> > Is there any way to distinguish between real definitions and synthetic
> ones?
>
> You are looking for declarations.is_artificial property
>
>
> http://language-binding.net/pygccxml/apidocs/pygccxml.declarations.declaration.declaration_t-class.html#is_artificial


Sorry, I should look better in the documentation next time.

I am having a minor problem, pygccxml is reporting all type declarations as
artificial.  To work around it, I only check for is_artificial for calldef_t
declarations and now everything works.

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] compiler generated declarations?

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

On Wed, Aug 27, 2008 at 5:04 PM, Gustavo Carneiro <gjc...@gm...> wrote:
> I am having a minor problem, pygccxml is reporting all type declarations as
> artificial.  To work around it, I only check for is_artificial for calldef_t
> declarations and now everything works.

The problem comes from the gccxml itself. I think it worth to report
this problem to Brad King. It is also possible that I don't understand
its meaning.

Only few calldefs could be artificial:
* default constructor
* copy constructor
* operator=

pygccxml has few type traits which help to identify whether class:
* default constructable
* has available copy constructor/operator=

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