[GCC-XML] wrong artificial op=()

Brad King brad.king at kitware.com
Sat Oct 4 17:35:09 EDT 2008


Axel Naumann wrote:
>> This code compiles fine with gccxml, but const_container class
>> description doesn't contain artificial default constructor. At the
>> same time, it contains default copy constructor.
>>
>> I am not C++ expert, but I think the class should have default
>> constructor.
> 
> I believe you're not testing what you think you are. Check this code
> out, e.g. with GCC 4.3.1, slightly modified from your code:
> 
> $ cat gccxmlml.cxx
> struct const_item{ const int values[10]; };
> void test_const_item() { const_item x;}
> struct const_container{ const const_item items[10]; };
> void test_const_container() { const_container x;}
> 
> $ g++ -c gccxmlml.cxx
> gccxmlml.cxx: In function 'void test_const_item()':
> gccxmlml.cxx:2: error: structure 'x' with uninitialized const members
> gccxmlml.cxx: In function 'void test_const_container()':
> gccxmlml.cxx:4: error: structure 'x' with uninitialized const members
> 
>> I think the class should have default constructor.
> 
> GCC disagrees, and for a good reason. The standard states that an
> implicitly implemented default constructor will make the program
> ill-formed if a user provided default constructor with empty initializer
> list and empty body would make the program ill-formed. As you probably
> know a const member _has_ to be initialized during construction, it must
> be part of the constructor's initializer list:
> 
> $ cat gccxmlml1.cxx
> struct Go {const int i; Go(): i(42) {} };
> struct NoGo {const int i; NoGo() {} };
> 
> $ g++ -c gccxmlml1.cxx
> gccxmlml1.cxx: In constructor 'NoGo::NoGo()':
> gccxmlml1.cxx:2: error: uninitialized member 'NoGo::i' with 'const' type
> 'const int'
> 
> For obvious reasons (but check the standard 12.8.7 if you want to see
> the proof) this restriction does not exist for the copy constructor.
> 
> Summary: I believe the standard forbids the default constructor that you
> want to see, and that GCCXML with Brad's patch generates the proper
> constructors and assignment operators.

Axel is correct according to C++98 12.1/7, and the recent patch detects 
this case.  Its attempt to synthesize these methods fails with the 
errors above (but I suppress the messages).  You can confirm this by 
running gccxml with "-fpermissive" to prevent the synthesization test 
from failing for these methods.

-Brad



More information about the gccxml mailing list