Virtual Assignment Operator in Protocol class

[N4M]

Dear,
Suppose I have a Protocol class, in which I need also an assignment
operator =().
class B
{
.....
virtual B& operator=(const B& rb) =0;
};
Now in some derived class D: public B, how would I proceed with
operator=? Do I need to supply 2 operators:
-01 to override D& operator=(const B& d)
-and 01 to overload D& operator=(const D& d)?
How about the (im)purality of = ?
Thanks for your guidance.

[Karl Heinz Buchegger]

N4M wrote:

Dear,
Suppose I have a Protocol class, in which I need also an assignment
operator =().
class B
{
....
virtual B& operator=(const B& rb) =0;
};
Now in some derived class D: public B, how would I proceed with
operator=? Do I need to supply 2 operators:
-01 to override D& operator=(const B& d)
-and 01 to overload D& operator=(const D& d)?
How about the (im)purality of = ?
Thanks for your guidance.

In a nutshell: having op= as virtual is seldome a good idea. Mostly
because it doesn't work how most people would expect it to work.
Hint: polymorphism works only by examining the object the function
is called for, but doesn't take the runtime type of the arguments
into account.

Assume class D, derived from class B

B* p1 = new D;
B* p2 = new D;

*p1 = *p2;

In the above, what do you think the compiler is looking for
when searching a function to fullfil the request of the
assignment? :

1) B::operator=( const B& Arg );
or 2) B::operator=( const D& Arg );
or 3) D::operator=( const B& Arg );
or 4) D::operator=( const D& Arg );

--
Karl Heinz Buchegger
kb******@gascad .at

[Karl Heinz Buchegger]

Karl Heinz Buchegger wrote:

N4M wrote:

Dear,
Suppose I have a Protocol class, in which I need also an assignment
operator =().
class B
{
....
virtual B& operator=(const B& rb) =0;
};
Now in some derived class D: public B, how would I proceed with
operator=? Do I need to supply 2 operators:
-01 to override D& operator=(const B& d)
-and 01 to overload D& operator=(const D& d)?
How about the (im)purality of = ?
Thanks for your guidance.
In a nutshell: having op= as virtual is seldome a good idea. Mostly
because it doesn't work how most people would expect it to work.
Hint: polymorphism works only by examining the object the function
is called for, but doesn't take the runtime type of the arguments
into account.

After rethinking (and smoking a cigarette) I don't think this to be
relevant any more. Read on ...

Assume class D, derived from class B

B* p1 = new D;
B* p2 = new D;

*p1 = *p2;

In the above, what do you think the compiler is looking for
when searching a function to fullfil the request of the
assignment? :

1) B::operator=( const B& Arg );
or 2) B::operator=( const D& Arg );
or 3) D::operator=( const B& Arg );
or 4) D::operator=( const D& Arg );

Next thought experiment (you might want to try this with your compiler
anyway): make the operator virtual.
Which op= is called then?

Hint: Think about what a dereference operation does when the runtime
type of an object differs from the static type of the pointer pointing
to it.

--
Karl Heinz Buchegger
kb******@gascad .at

[Risto Lankinen]

"Karl Heinz Buchegger" <kb******@gasca d.at> wrote in message
news:41******** *******@gascad. at...

In a nutshell: having op= as virtual is seldome a good idea. Mostly
because it doesn't work how most people would expect it to work.
Hint: polymorphism works only by examining the object the function
is called for, but doesn't take the runtime type of the arguments
into account.
Then programmer must do that, no?
Assume class D, derived from class B

B* p1 = new D;
B* p2 = new D;

*p1 = *p2;

In the above, what do you think the compiler is looking for
when searching a function to fullfil the request of the
assignment? :

1) B::operator=( const B& Arg );
or 2) B::operator=( const D& Arg );
or 3) D::operator=( const B& Arg );
or 4) D::operator=( const D& Arg );
The symptoms you demonstrate do not exist (nor become better
or worse) because of virtual assignment, but because of how
C++ object model works. In real world, virtual assignment is not
the disease, but the cure!

Consider this example:

// =============== =============== ==========

struct B
{
// this is a pretty canonical class, except for virtual assignment

virtual B &operator=( const B & );

// virtual destructor needed for derived deletion thru base *

virtual ~B();

// add more members (data or functions) to suit the taste...
};
struct D : public B
{
int value;

D( int i=0 ) : value(i)
{
}

D( const D &r ) : B(r) , value(r.value)
{
}

virtual D &operator=( const D &r )
{
B::operator=( r );
value = r.value;
return *this;
}

virtual B &operator=( const B &r )
{
const D *p = dynamic_cast<co nst D *>(&r);

if( p )
{
*this = *p;
}
else
{
// D is being sliced, but now you can detect and compensate!!!
B::operator=( r );
value = 0;
}

return *this;
}
};

// =============== =============== ==========

Now your example...
B* p1 = new D;
B* p2 = new D;

*p1 = *p2;
.... will assign as-if using the most intuitive choice...
1) B::operator=( const B& Arg );
or 2) B::operator=( const D& Arg );
or 3) D::operator=( const B& Arg );
or 4) D::operator=( const D& Arg );

.... which, of course, is 4 .

- Risto -

[Karl Heinz Buchegger]

Risto Lankinen wrote:

... which, of course, is 4 .

- Risto -

Thanks for bringing me back on track.
I don't know why, but somehow I always get lost when
thinking about a virtual op= :-)
--
Karl Heinz Buchegger
kb******@gascad .at

[N4M]

"Risto Lankinen" <rl******@hotma il.com> wrote in message news:<fE******* ************@ne ws1.nokia.com>. ..

"Karl Heinz Buchegger" <kb******@gasca d.at> wrote in message
news:41******** *******@gascad. at...

Thanks for your example, but what if it is insisted to have all
operators and functions in the ABC be PURE ? Then I cannot initiate B
b...
That's driving my crazy.
N4M

[N4M]

"Risto Lankinen" <rl******@hotma il.com> wrote in message news:<fE******* ************@ne ws1.nokia.com>. ..

"Karl Heinz Buchegger" <kb******@gasca d.at> wrote in message
news:41******** *******@gascad. at...

Thanks for your example, but what if it is insisted to have all
operators and functions in the ABC be PURE ? Then I cannot initiate B
b...
That's driving my crazy.
N4M

[Karl Heinz Buchegger]

N4M wrote:

"Risto Lankinen" <rl******@hotma il.com> wrote in message news:<fE******* ************@ne ws1.nokia.com>. ..

"Karl Heinz Buchegger" <kb******@gasca d.at> wrote in message
news:41******** *******@gascad. at...

Thanks for your example, but what if it is insisted to have all
operators and functions in the ABC be PURE ? Then I cannot initiate B
b...
That's driving my crazy.

I don't understand.

Making those functions PURE (by adding = 0), doesn't mean that
you cannot provide an implementation for them :-)

--
Karl Heinz Buchegger
kb******@gascad .at

[Daniel T.]

dn******@yahoo. com (N4M) wrote:

Dear,
Suppose I have a Protocol class, in which I need also an assignment
operator =().
class B
{
....
virtual B& operator=(const B& rb) =0;
};
Now in some derived class D: public B, how would I proceed with
operator=?
Let's consider this tree:

class B {
public:
virtual ~B() { }
virtual B& operator=( const B& ) = 0;
};

class D {
int foo;
public:
virtual B& operator=( const B& );
};

class C {
double bar;
public:
virtual B& operator=( const B& );
};

Can either D::op= or C::op= be implemented reasonably? I don't think so.
What is supposed to happen with this code?

void fun( B& b1, B& b2 ) {
b1 = b2;
}

If b1 is an D and b2 is a C?

Do I need to supply 2 operators:
-01 to override D& operator=(const B& d)
You need to provide this one.
-and 01 to overload D& operator=(const D& d)?

You would only need this one if something in the class requires it,
otherwise it will be created properly for you.

The moral of the story here is "don't provide a pure virtual op=".

[Risto Lankinen]

"Daniel T." <po********@eat hlink.net> wrote in message news:postmaster->

Let's consider this tree:

class B {
public:
virtual ~B() { }
virtual B& operator=( const B& ) = 0;
};

class D {
int foo;
public:
virtual B& operator=( const B& );
};

class C {
double bar;
public:
virtual B& operator=( const B& );
};

Can either D::op= or C::op= be implemented reasonably?
Absolutely. Here's one way:

B &D::operator =( const B &r )
{
const D *p = dynamic_cast<co nst D *>(&r);
if( p )
foo = p->foo;
else
throw "Silly assignment!";
return *this;
}

B &C::operator =( const B &r )
{
const C *p = dynamic_cast<co nst C *>(&r);
if( p )
bar = p->bar;
else
throw "Silly assignment!";
return *this;
}
What is supposed to happen with this code?

void fun( B& b1, B& b2 ) {
b1 = b2;
}

If b1 is an D and b2 is a C?
With virtual assignment, it would throw a "Silly assignment!"
exception (or alternatively, whatever else the author of the
class D deems appropriate for the case when, so to speak,
an Orange is assigned to a Banana thru a reference to Fruit).

WithOUT virtual assignment it would create a banana the size
of a grape, with an orange skin that doesn't need to be peeled
before eating.
The moral of the story here is "don't provide a pure virtual op=".

This belief, I think, needs reconsideration .

- Risto -