Reference to an undefined assignment operator of a base class in a derived class.
in [Visual C]
|
From: Vladimir Grigoriev on 18 Dec 2009 09:09 Let consider the following code struct A { A( int i = 0 ): x( i ) {} int x; }; struct B: public A { B( int i = 0 ): A( i ), value( x ) {} B( const B &rhs ): A( rhs ), value( x ) {} B & operator =( const B &rhs ) { A::operator =( rhs ); return ( *this ); } int &value; }; As you can see in the base class there is no an assignment operator defined explicitly. However in the derived class there is explicit reference to the assignment operator of the base class. The problem is the following. When I use some non-Microsoft compiler it issues an error for this code. However if I will include an assignment operator in the base class explicitly the error dissapears. The Microsoft compiler VC++ 2005 EE compiles the code without any error. Is it a bug of the non-Microsoft compiler? May I specify explicitly an assignment operator in a derived class when in a base class it is absent and defined by default by a compiler? What does C++ standard say about this? Also as you can see as for a copy constructor there is not such problem when the code compiled with the non-Micosoft compiler. Vladimir Grigoriev
From: Igor Tandetnik on 18 Dec 2009 09:41 Vladimir Grigoriev wrote: > Let consider the following code > > struct A > { > A( int i = 0 ): x( i ) {} > int x; > }; > > struct B: public A > { > B( int i = 0 ): A( i ), value( x ) {} > B( const B &rhs ): A( rhs ), value( x ) {} > B & operator =( const B &rhs ) > { > A::operator =( rhs ); > return ( *this ); > } > int &value; > }; > > As you can see in the base class there is no an assignment operator defined > explicitly. However in the derived class there is explicit reference to the > assignment operator of the base class. > > The problem is the following. When I use some non-Microsoft compiler it > issues an error for this code. However if I will include an assignment > operator in the base class explicitly the error dissapears. > The Microsoft compiler VC++ 2005 EE compiles the code without any error. > Is it a bug of the non-Microsoft compiler? Yes. The code is correct as written. > May I specify explicitly an > assignment operator in a derived class when in a base class it is absent and > defined by default by a compiler? Yes. > What does C++ standard say about this? Nothing in particular, beyond the fact that 12.8p10 ...An implicitly-declared copy assignment operator is an inline public member of its class... There's just nothing special about an implicitly declared assignment operator, as compared to its explicitly declared brethren. It's a class member function like any other. > Also as you can see as for a copy constructor there is not such problem when > the code compiled with the non-Micosoft compiler. Well, I can't see that - I don't have a copy of that mysterious "non-Microsoft compiler". But I trust you at your word. -- With best wishes, Igor Tandetnik With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925
From: Vladimir Grigoriev on 18 Dec 2009 10:23 "Igor Tandetnik" <itandetnik(a)mvps.org> wrote in message news:%237mqoA$fKHA.1540(a)TK2MSFTNGP06.phx.gbl... Well, I can't see that - I don't have a copy of that mysterious "non-Microsoft compiler". But I trust you at your word. -- With best wishes, Igor Tandetnik This mysterious "non_Microsoft compiler" is the old Borland C++ Builder 5.0 compiler. By the way it does not have the bug of Microsoft C++ STL vector implementation as Visual C++ 2005 does have which I pointed out early.:) So the problem is haw to join these compilers together such a way that at least a simple C++ program exept "Hello world" would be compiled according to the C++ standard.:) Vladimir Grigoriev .. With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925
From: Vladimir Grigoriev on 21 Dec 2009 06:40 I think that this effect is relative to the BORLAND compatible option in the project properties. If to select the ANSI compatible option the problem dissapears. Maybe it is relative to the Borland VCL library that is used in C++ and in Pascal simultaneously. Vladimir Grigoriev "Victor Bazarov" <v.Abazarov(a)comAcast.net> wrote in message news:hggiv8$o30$2(a)news.datemas.de... > Darko Miletic wrote: >> Vladimir Grigoriev wrote: >>> Let consider the following code >>> >>> struct A >>> { >>> A( int i = 0 ): x( i ) {} >>> int x; >>> }; >>> >>> struct B: public A >>> { >>> B( int i = 0 ): A( i ), value( x ) {} >>> B( const B &rhs ): A( rhs ), value( x ) {} >>> B & operator =( const B &rhs ) >>> { >>> A::operator =( rhs ); >>> return ( *this ); >>> } >>> int &value; >>> }; >>> >> >> Compiling that code in BDS 2006 (bcc32 5.8 ) I get the following error: >> >> [C++ Error] Unit1.cpp(17): E2451 Undefined symbol '=' >> Unit1.cpp(10): class B >> Unit1.cpp(21): decision to instantiate: B & B::operator =(const B &) >> --- Resetting parser context for instantiation... >> Unit1.cpp(16): parsing: B & B::operator =(const B &) >> >> However adding definition of destructor in class A and B problem goes >> away: >> >> >> struct A { >> A( int i = 0 ): x( i ) {} >> virtual ~A(void) {} >> int x; >> }; >> >> struct B: public A >> { >> B( int i = 0 ): A( i ), value( x ) {} >> B( const B &rhs ): A( rhs ), value( x ) {} >> virtual ~B(void) {} >> B & operator =( const B &rhs ) >> { >> A::operator =( rhs ); >> return ( *this ); >> } >> int &value; >> }; > > Wow... No surprise nobody uses that compiler anymore. > > V > -- > Please remove capital 'A's when replying by e-mail > I do not respond to top-posted replies, please don't ask
|
Pages: 1 Prev: Warning C4180 in Visual C++ 2005 EE Next: extern for global variable: C Question |