|
From: Gustavo C. <gjc...@gm...> - 2008-10-15 17:07:28
|
Sorry, Roman, I really meant to send to the mailing list! :-)
---------- Forwarded message ----------
From: Gustavo Carneiro <gjc...@gm...>
Date: 2008/10/15
Subject: instance attribute with anonymous enum type
To: Roman Yakovenko <rom...@gm...>
Hello, I am hitting a problem in pygccxml regarding anonymous enums used as
class member variables.
Something like this:
class SomeObject
{
public:
enum {
TYPE_FOO,
TYPE_BAR,
} type;
};
When I scan this, pygccxml tells me the attribute 'type' of 'SomeObject' is
of type 'SomeObject'. I happily try to generate code for this, and of
course the generated code does not even compile:
[14/25] cxx: build/default/tests/foomodule2.cc ->
build/default/tests/foomodule2_9.o
default/tests/foomodule2.cc: In function 'int
_wrap_PySomeObject__set_type(PySomeObject*, PyObject*)':
default/tests/foomodule2.cc:6211: error: cannot convert 'SomeObject' to
'SomeObject::<anonymous enum>' in assignment
Build failed
It would be better if pygccxml reported the type as "SomeObject::<anonymous
enum>", like GCC does. This way at least I will not be lead me to generate
invalid code (I prefer no code at all than erroneous code).
This with pygccxml 0.9.5, gccxml 2008-04-20.
My work around for the moment is:
real_type = type_traits.remove_declarated(member.type)
if hasattr(real_type, 'name') and not real_type.name:
print >> sys.stderr, ">>>>>>>>>>>>>> skip anonymous
type"
continue
Take care,
--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
|
|
From: Roman Y. <rom...@gm...> - 2008-10-15 19:15:58
|
On Wed, Oct 15, 2008 at 7:06 PM, Gustavo Carneiro <gjc...@gm...> wrote:
> Sorry, Roman, I really meant to send to the mailing list! :-)
Hi. That's okey.
> From: Gustavo Carneiro <gjc...@gm...>
>
> Hello, I am hitting a problem in pygccxml regarding anonymous enums used as
> class member variables.
>
> Something like this:
>
> class SomeObject
> {
> public:
>
> enum {
> TYPE_FOO,
> TYPE_BAR,
> } type;
> };
>
> When I scan this, pygccxml tells me the attribute 'type' of 'SomeObject' is
> of type 'SomeObject'. I happily try to generate code for this, and of
> course the generated code does not even compile:
>
> [14/25] cxx: build/default/tests/foomodule2.cc ->
> build/default/tests/foomodule2_9.o
> default/tests/foomodule2.cc: In function 'int
> _wrap_PySomeObject__set_type(PySomeObject*, PyObject*)':
> default/tests/foomodule2.cc:6211: error: cannot convert 'SomeObject' to
> 'SomeObject::<anonymous enum>' in assignment
> Build failed
Indeed, pygccxml has a problem to create full type name for unnamed
types, and the solution I choose, is to report named parts only.
> It would be better if pygccxml reported the type as "SomeObject::<anonymous
> enum>", like GCC does. This way at least I will not be lead me to generate
> invalid code (I prefer no code at all than erroneous code).
How? You still will have to check whether the type has name or not and
avoid the generation.
More over in this concrete example, you can do better. You can expose
all enum values as int within the class scope. Member variable "type"
could also be exposed as int.
Yes, this is a special case, but it could be completely handled by
code generator.
> This with pygccxml 0.9.5, gccxml 2008-04-20.
>
> My work around for the moment is:
>
> real_type = type_traits.remove_declarated(member.type)
> if hasattr(real_type, 'name') and not real_type.name:
> print >> sys.stderr, ">>>>>>>>>>>>>> skip anonymous
> type"
> continue
As I said unnamed types is a special case.
Py++ has solution for this and other issues. It extends every
declaration class, defined in pygccxml. One of the functions, it adds
is the ability of declarations to analyze "itself" and report
problems, and whether it could be exported or not.
For example:
http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/enumeration_wrapper.py?view=markup
http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/calldef_wrapper.py?revision=1428&view=markup
take a look on _exportable_impl method.
Thus the actual "code generator" code is clear, because it doesn't
need to deal with such cases. It just asks the declaration.
HTH
P.S. Hope I was clear. If not we can discuss it using IRC or gmail
chat. I have some free time now.
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
|
|
From: Gustavo C. <gjc...@gm...> - 2008-10-15 23:52:02
|
2008/10/15 Roman Yakovenko <rom...@gm...>
> On Wed, Oct 15, 2008 at 7:06 PM, Gustavo Carneiro <gjc...@gm...>
> wrote:
> > Sorry, Roman, I really meant to send to the mailing list! :-)
>
> Hi. That's okey.
>
> > From: Gustavo Carneiro <gjc...@gm...>
> >
> > Hello, I am hitting a problem in pygccxml regarding anonymous enums used
> as
> > class member variables.
> >
> > Something like this:
> >
> > class SomeObject
> > {
> > public:
> >
> > enum {
> > TYPE_FOO,
> > TYPE_BAR,
> > } type;
> > };
> >
> > When I scan this, pygccxml tells me the attribute 'type' of 'SomeObject'
> is
> > of type 'SomeObject'. I happily try to generate code for this, and of
> > course the generated code does not even compile:
> >
> > [14/25] cxx: build/default/tests/foomodule2.cc ->
> > build/default/tests/foomodule2_9.o
> > default/tests/foomodule2.cc: In function 'int
> > _wrap_PySomeObject__set_type(PySomeObject*, PyObject*)':
> > default/tests/foomodule2.cc:6211: error: cannot convert 'SomeObject' to
> > 'SomeObject::<anonymous enum>' in assignment
> > Build failed
>
> Indeed, pygccxml has a problem to create full type name for unnamed
> types, and the solution I choose, is to report named parts only.
>
> > It would be better if pygccxml reported the type as
> "SomeObject::<anonymous
> > enum>", like GCC does. This way at least I will not be lead me to
> generate
> > invalid code (I prefer no code at all than erroneous code).
>
> How? You still will have to check whether the type has name or not and
> avoid the generation.
If the type string returned by pygccxml was simply "SomeObject::<anonymous
enum>", I would not have to do anything in my case (pybindgen). That type
is not registered, and so an exception like
TypeLookupError("SomeObject::<anonymous enum>") would be raised and printed
to the user as warning, but no code would be generated for that definition.
>
>
> More over in this concrete example, you can do better. You can expose
> all enum values as int within the class scope. Member variable "type"
> could also be exposed as int.
>
> Yes, this is a special case, but it could be completely handled by
> code generator.
Yes. I know it is possible wrap it. Maybe some day I will wrap it, but I
don't have time for everything, and I don't need that feature right now ;-)
>
>
> > This with pygccxml 0.9.5, gccxml 2008-04-20.
> >
> > My work around for the moment is:
> >
> > real_type = type_traits.remove_declarated(member.type)
> > if hasattr(real_type, 'name') and not real_type.name:
> > print >> sys.stderr, ">>>>>>>>>>>>>> skip anonymous
> > type"
> > continue
>
> As I said unnamed types is a special case.
Personally I think it is deceptive to return a type expression that does not
correspond to the real type. I mean, it's worse, it is returning a type
string that corresponds to _another_ type, one which is perfectly valid.
This induces the code generator to generate incorrect code...
>
>
> Py++ has solution for this and other issues. It extends every
> declaration class, defined in pygccxml. One of the functions, it adds
> is the ability of declarations to analyze "itself" and report
> problems, and whether it could be exported or not.
>
> For example:
>
> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/enumeration_wrapper.py?view=markup
>
>
> http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pyplusplus_dev/pyplusplus/decl_wrappers/calldef_wrapper.py?revision=1428&view=markup
>
> take a look on _exportable_impl method.
>
> Thus the actual "code generator" code is clear, because it doesn't
> need to deal with such cases. It just asks the declaration.
Hm.. OK. I am more of a down to earth guy and prefer more simple and direct
solutions... at least to begin with :-)
But thanks for the tip.
--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
|
|
From: Roman Y. <rom...@gm...> - 2008-10-16 05:06:06
|
On Thu, Oct 16, 2008 at 1:51 AM, Gustavo Carneiro <gjc...@gm...> wrote: > Personally I think it is deceptive to return a type expression that does not > correspond to the real type. I mean, it's worse, it is returning a type > string that corresponds to _another_ type, one which is perfectly valid. > This induces the code generator to generate incorrect code... I will consider to change the behavior after the release. Can you open the bug, so I will not forget this. Thanks. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |
