[GCC-XML] last commit
Roman Yakovenko
roman.yakovenko at gmail.com
Thu Jun 12 14:49:32 EDT 2008
On Thu, Jun 12, 2008 at 9:20 PM, Brad King <brad.king at kitware.com> wrote:
> Roman Yakovenko wrote:
>> Brad, I found something strange in XML, generated by GCC-XML with the
>> latest patch. Also I am not sure whether this is GCCXML problem or my
>> lack of C++ knowledge.
>>
>> This is the smallest example I found:
>>
>> namespace is_noncopyable{ namespace detail{
>> struct BBB{ const int values[10]; };
>> void test_BBB(BBB by_value);
>> struct const_container{ const BBB items[10]; };
>> void test_const_container(const_container by_value);
>> } }
>>
>> struct AAA{ const int values[10]; };
>>
>> As you can see AAA and BBB struct has exactly same definition, but for
>> some reason GCCXML generates that AAA has:
>>
>> * constructor
>> * copy constructor
>> * operator=
>> * destructor
>> * variable
>>
>> but BBB has only variable and public destructor.
>>
>> If I comment declarations, that use BBB, than GCCXML generates all 5
>> declarations.
>
> This is very strange indeed. I reduced the example to just
>
> namespace N {
> struct A {};
> #if 1
> struct B0 { const A a; };
> #endif
> struct B { const A a; };
> }
>
> If you switch the "1" to a "0" then all the decls in "A" show up. I
> added some debugging output to the dump code. GCC doesn't even have an
> internal representation for the missing decls. Note the only difference
> is whether a struct whose _name_ has at least two characters contains a
> _const_ member of type A. Even stranger, if it is put outside a namespace:
>
> struct A {};
> struct B { const A a; };
>
> then the length of the name does not matter. Just having struct B is
> enough to block the decls. By commenting it out they all show up.
>
> This must be some strange quirk in the GCC parser implementation.
> Unfortunately we cannot report this as a bug to GCC folks unless we can
> produce a C++ example that won't compile.
:-(((( I am not sure we can create such code. The example is already
pretty simple.
> BTW, how did this change break your code?
I had 2 "same" classes, within different namespaces and for one gcc
reported all
5 declarations and for other only 2. And than
"has_default_constructor" test started to fail.
> All it did was start printing
> some declarations it didn't print before. How did you previously decide
> whether a class has default/copy constructors?
I implemented some logic on my own. Take a look on:
http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pygccxml_dev/pygccxml/declarations/type_traits.py?revision=1205&view=markup
http://pygccxml.svn.sourceforge.net/viewvc/pygccxml/pygccxml_dev/unittests/data/type_traits.hpp?revision=1205&view=markup
Look for has_copy_constructor, has_default_constructor, is_noncopyable
I also have pretty good unit tests for this functionality, but
unfortunately I made mistake in one of the use cases.
You don't :-), but if you ask me, I would revert last commit. The
previous situation was deterministic: only declarations, defined by
the users, were dumped. Now, I cannot even reliably apply my
"guesses".
Thanks
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
More information about the gccxml
mailing list