I am having a problem with (py)gccxml parsing of templated types, where a
different type is being reported.
For example, here:
std::set<uint32_t> get_set ();
With this code:
for fun in
module_namespace.free_functions(function=self.location_filter,
allow_empty=True,
recursive=False):
if fun.name.startswith('__'):
continue
for dependency in fun.i_depend_on_them(recursive=False):
type_info = dependency.depend_on_it
traits = container_traits.find_container_traits(type_info)
if traits is None:
continue
print >> sys.stderr, "** type: %s; ---> partial_decl_string:
%r" % (type_info, type_info.partial_decl_string)
It prints:
** type: std::set<unsigned int,std::less<unsigned
int>,std::allocator<unsigned int> >; ---> partial_decl_string: '::std::set<
unsigned int >'
Yes, I know what you are thinking, it's ok, unsigned int and uint32_t are
the same type after all. Well, usually it is, sometimes it's not. I
received a report about generated code not compiling in cygwin, and I found
out that it's because in cygwin uint32_t is typdefed as 'unsigned long int',
instead of 'unsigned int'. Yes, cygwin is broken, I know, but we have to
live with it :|
Is there anything that I can do to make this right? I would like to avoid
losing the type information and keep uint32_t around instead of unsigned
int, else the generated code is not very portable.
--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
|
