[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