rac@intrigue.com (Robert Coie) writes:

>Given the note in verse 2 of 13.5.3,
>
>Note: for a derived class D with a base class B for which a virtual copy
>assignment has been declared, the copy assignment operator in D does not
>override B's virtual copy assignment operator.
>
>I would assume that:
>
>struct A { virtual A & operator=( const A & ); };
>struct B : A { B & operator=( const A & ); };

B & B::operator =(const A &) is not a copy assignment operator, since
it does not take a single parameter of type B, B& or const B& (see 12.8/9).
It does override B's virtual copy assignment operator.
The note in 13.5.3/2 is talking about the implicitly generated copy
assignment operator B & B::operator =(const B &).  See the example
in 13.5.3.

>static void f( A & a )
>{
>   A * a2 = new A;
>   a = *a2;    // calls A::operator= ???

No, it calls calls B::operator =(const A &).

>}
>
>int main()
>{
>   B  b;
>   f( b );
>}

--
Fergus Henderson                       | I'll forgive even GNU emacs as
fjh@cs.mu.oz.au                        | long as gcc is available ;-)
http://www.cs.mu.oz.au/~fjh            |             - Linus Torvalds

Apologies to sites who receive two versions of this, previous post
cancelled due to egregious error in sample code.

Given the note in verse 2 of 13.5.3,

Note: for a derived class D with a base class B for which a virtual copy
assignment has been declared, the copy assignment operator in D does not
override B's virtual copy assignment operator.

I would assume that:

struct A { virtual A & operator=( const A & ); };
struct B : A { B & operator=( const A & ); };

static void f( A & a )
{
   A * a2 = new A;
   a = *a2;    // calls A::operator= ???
}

int main()
{
   B  b;
   f( b );
}

If this is the case, and B::operator= is not invoked in the commented
line, what is the point of virtual copy assignment operators?

Robert Coie                              rac@intrigue.com
Implementor, Intrigue Corporation     AppleLink: INTRIGUE

In article <rac-1905951238280001@intrigue.intrigue.com>,
Robert Coie <rac@intrigue.com> wrote:
:Apologies to sites who receive two versions of this, previous post
:cancelled due to egregious error in sample code.
:
:Given the note in verse 2 of 13.5.3,
:
:Note: for a derived class D with a base class B for which a virtual copy
:assignment has been declared, the copy assignment operator in D does not
:override B's virtual copy assignment operator.
:
:I would assume that:
:
:struct A { virtual A & operator=( const A & ); };
:struct B : A { B & operator=( const A & ); };
:
:static void f( A & a )
:{
:   A * a2 = new A;
:   a = *a2;    // calls A::operator= ???
:}
:
:int main()
:{
:   B  b;
:   f( b );
:}
:
:If this is the case, and B::operator= is not invoked in the commented
:line, what is the point of virtual copy assignment operators?
:
:Robert Coie                              rac@intrigue.com
:Implementor, Intrigue Corporation     AppleLink: INTRIGUE

I believe that the note means that your commented line will not invoke
B::operator=( const B & ).  It will still invoke B::operator= ( const A & ).
--
Stephen Gevers
sg3235@shelob.sbc.com

In article 1905951238280001@intrigue.intrigue.com, rac@intrigue.com (Robert Coie) writes:
>Given the note in verse 2 of 13.5.3,
>
>Note: for a derived class D with a base class B for which a virtual copy
>assignment has been declared, the copy assignment operator in D does not
>override B's virtual copy assignment operator.
>
>I would assume that:
>
>struct A { virtual A & operator=( const A & ); };
>struct B : A { B & operator=( const A & ); };
>
>static void f( A & a )
>{
>   A * a2 = new A;
>   a = *a2;    // calls A::operator= ???
>}
>
>int main()
>{
>   B  b;
>   f( b );
>}
>

No, the marked line calls B::operator=(const A&). There is an example very
much like yours on the same page where you found the note (continued onto the
next page).

I believe the note is pointing out that D's copy-assignment operator
 D::operator=(const D&)
does not override B's copy-assignment operator
 B::operator=(const B&)
because the parameter types are different.
---
Steve Clamage, stephen.clamage@eng.sun.com