Why assignment operator is'nt inherited?

[vj]

Hi Friends,

I was going through a C++ reference book when this rule caught my eye:

-->Assignment operator '=' is not inherited by the sub class.

I cannot figure out why this rule has being imposed and how it actually
makes any sense. If operator '=' cannot be inherited then it should not
be allowed to be made virtual . But following declaration on VC 6.0
compiler gets through :
/*****************************************/
class Parent
{....
public :
.....
virtual Parent & operator =(Parent & p) // !!!!
{return *this;}
};
/*****************************************/

If not inherited then why let it be a virtual function !!!

Any ideas as why is this happening?

Thanks,
VJ

[Alf P. Steinbach]

* vj:

Hi Friends,

I was going through a C++ reference book when this rule caught my eye:

-->Assignment operator '=' is not inherited by the sub class.
That is incorrect (which "reference book" are you reading?).

A copy assignment operator for a class Base does not have the signature
required for a copy assignment operator for a class Derived. It is
inherited by Derived, but does not constitute a copy assignment operator
in Derived. So even though assignment operators are inherited, just
like other member functions, that does not provide copy assignment.

I cannot figure out why this rule has being imposed and how it actually
makes any sense.

There is no such rule.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[vj]

Here is the excert from the book -

"In addition, the operator= doesn't inherit because it performs a
constructor-like activity. That is, just because you know how to
assign all the members of an object on the left-hand side of the =
from an object on the right-hand side doesn't mean that assignment
will still have the same meaning after inheritance."
-- Thinking in C++, Bruce Eckel , Pg 631

[Alf P. Steinbach]

* vj:

Here is the excert from the book -

"In addition, the operator= doesn't inherit because it performs a
constructor-like activity. That is, just because you know how to
assign all the members of an object on the left-hand side of the =
from an object on the right-hand side doesn't mean that assignment
will still have the same meaning after inheritance."
-- Thinking in C++, Bruce Eckel , Pg 631

Ah, the thinking Bruce... Well, just ignore the first sentence. It's
wrong (you might check if there's an errata page, these things happen).
Second Bruce: G'day, Bruce!

First Bruce: Oh, Hello Bruce!

Third Bruce: How are you Bruce?

First Bruce: A bit crook, Bruce.

Second Bruce: Where's Bruce?

First Bruce: He's not 'ere, Bruce.

Third Bruce: Blimey, it's hot in here, Bruce.

First Bruce: Hot enough to boil a monkey's bum!

Second Bruce: That's a strange expression, Bruce.

First Bruce: Well Bruce, I heard the Prime Minister use it. "It's hot
enough to boil a monkey's bum in here, your Majesty," he said and she
smiled quietly to herself.

Third Bruce: She's a good Sheila Bruce, and not at all stuck up.

Second Bruce: Here! Here's the boss-fellow now! - how are you bruce?

(Enter fourth Bruce with English person, Michael)

Fourth Bruce: 'Ow are you, Bruce?

First Bruce: G'day Bruce!

Fourth Bruce: Bruce.

Second Bruce: Hello Bruce.

Fourth Bruce: Bruce.

Third Bruce: How are you, Bruce?

Fourth Bruce: G'day Bruce.

Fourth Bruce: Gentleman, I'd like to introduce man from Pommeyland who
is joinin' us this year in the philosophy department at the University
of Walamaloo.

Everybruce: G'day!

Michael: Hello.

Fourth Bruce: Michael Baldwin, Bruce. Michael Baldwin, Bruce. Michael
Baldwin, Bruce.

First Bruce: Is your name not Bruce?

Michael: No, it's Michael.

Second Bruce: That's going to cause a little confusion.

Third Bruce: Mind if we call you "Bruce" to keep it clear?

Fourth Bruce: Gentlemen, I think we better start the faculty meeting.
Before we start, though, I'd like to ask the padre for a prayer.

First Bruce: Oh Lord, we beseech Thee, Amen!!

Everybruce: Amen!

Fourth Bruce: Crack tubes! (Sound of cans opening) Now I call upon Bruce
to officially welcome Mr. Baldwin to the philosophy faculty.

Second Bruce: I'd like to welcome the pommey bastard to God's own Earth,
and remind him that we don't like stuck-up sticky-beaks here.

Everybruce: Hear, hear! Well spoken, Bruce!

Fourth Bruce: Bruce here teaches classical philosophy, Bruce there
teaches Haegelian philosophy, and Bruce here teaches logical positivism.
And is also in charge of the sheep dip.

Third Bruce: What's New-Bruce going to teach?

Fourth Bruce: New-Bruce will be teaching political science, Machiavelli,
Bentham, Locke, Hobbes, Sutcliffe, Bradman, Lindwall, Miller, Hassett,
and Benaud.

Second Bruce: Those are all cricketers!

Fourth Bruce: Aww, spit!

Third Bruce: Hails of derisive laughter, Bruce!

Everybruce: Australia, Australia, Australia, Australia, we love you amen!

Fourth Bruce:Bruce: Crack tube! (Sound of cans opening) Any questions?

Second Bruce: New-Bruce, are you a Poofter?

Fourth Bruce: Are you a Poofter?

Michael: No!

Fourth Bruce: No. Right, I just want to remind you of the faculty rules:
Rule One!

Everybruce: No Poofters!

Fourth Bruce: Rule Two, no member of the faculty is to maltreat the
Abbos in any way at all -- if there's anybody watching. Rule Three?

Everybruce: No Poofters!!

Fourth Bruce: Rule Four, now this term, I don't want to catch anybody
not drinking. Rule Five,

Everybruce: No Poofters!

Fourth Bruce: Rule Six, there is NO ... Rule Six. Rule Seven,

Everybruce: No Poofters!!

Fourth Bruce: Right, that concludes the readin' of the rules, Bruce.

First Bruce: This here's the wattle, the emblem of our land. You can
stick it in a bottle, you can hold it in your hand.

Everybruce: Amen!

CC: Michael. Er, ..., Bruce.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Ron Natalie]

vj wrote:

Here is the excert from the book -

"In addition, the operator= doesn't inherit because it performs a
constructor-like activity. That is, just because you know how to
assign all the members of an object on the left-hand side of the =
from an object on the right-hand side doesn't mean that assignment
will still have the same meaning after inheritance."
-- Thinking in C++, Bruce Eckel , Pg 631

That's a pretty wierd statement. Assignment operators don't do
constructor like activities at all. You make mistakes if you
think about them that way as you must take care of the already
constructed things in the left hand side of the operator.

The C++ language doesn't really define inheritance. Inheritance
of member functions is just an effect of the defined behavior of
base class name resolution. The reason operator= doesn't appear
to inherit is because the fact that there's always a copy assignment
operator in the derived class (either declared expclicitly by
the programmer or implicitly by the compiler) that hides any
base class.

If you bring the name forward with a using declaration, the op
inherits as any other function:
struct base {
base& operator=(const base&) {
cout << "base op=";
return *this;
};
};

struct derived : base {
using base::operator=;
derived& operator=(const derived&) {
cout << "derived op=";
return *this;
}
};

int main(int argc, char* argv[])
{
base b;
derived d;

d = b; // prints base op=
return 0;
}
It's similar semantic rules that keep a templated function from
ever being a copy constructor.

[vj]

I think i will have to kick this book and send it to the dust bin :-)
....
Any ways i have one more intresting issue. Please take a look at the
code below:-

class Parent
{int m1;
public :
Parent(int m) {m1=m;}
virtual void show() {cout<<"Parent :"<<m1<<endl;}
};

class Child: public Parent
{int m2;
public:
Child(int m2,int m1):Parent(m1)
{this->m2=m2;}
void show() {cout<<"Child :"<<m2<<endl;}
void showp() {Parent::show();}
};
void main()
{ Child ch1(10,10),ch2(20,20);
Parent *pp=&ch1;
*pp=ch2; // assign obj ch2 to ch1 via pointer derefrence
ch1.show();
ch2.show();

cout<<endl<<"Parents"<<endl<<"******************** *"<<endl;
ch1.showp();
ch2.showp();
cin.get();
}
/***************************************/
Output:
Child :10
Child :20

Parents
*********************
Parent :20
Parent :20

Intrestingly only parent objects seems to be equated hoever child
object memeber m2 remains the same. I think the pointer derefence
problem again calls for virtual assignment operator function !!!

What do you think?

VJ

[Ron Natalie]

vj wrote:

I think i will have to kick this book and send it to the dust bin :-)
...
Any ways i have one more intresting issue. Please take a look at the
code below:-

class Parent
{int m1;
public :
Parent(int m) {m1=m;}
virtual void show() {cout<<"Parent :"<<m1<<endl;}
};

class Child: public Parent
{int m2;
public:
Child(int m2,int m1):Parent(m1)
{this->m2=m2;}
void show() {cout<<"Child :"<<m2<<endl;}
void showp() {Parent::show();}
};
void main()
{ Child ch1(10,10),ch2(20,20);
Parent *pp=&ch1;
*pp=ch2; // assign obj ch2 to ch1 via pointer derefrence
You're calling pp->Parent::operator=(ch2) here.
All that does is copy the parent subpart of the ch2 object to ch1ld
it knows nothing about the child class.

Intrestingly only parent objects seems to be equated hoever child
object memeber m2 remains the same. I think the pointer derefence
problem again calls for virtual assignment operator function !!!

You could implement it if you wanted. But what are you going to
do when the dynamic type of the left hand side of = is different
than the dynamnic type of the right hand side.

[vj]

You could implement it if you wanted. But what are you going to
do when the dynamic type of the left hand side of = is different
than the dynamnic type of the right hand side.

I agree to that point But is'nt this the same problem that virtual
functions were destined to solve. If this call *pp=ch would
have called 'Child::operator = ' rather than 'Parent::operator ='
then there would have being no problem as such since child would
have also equated thier encapsulated parent class objects. Thus in
effect both m1, m2 would have being equated. Hence the issue of
dynamic type of L Value could have better being handled if

---If Operator = (Parent &) is inherited ( which they are :-) )
---They were virtual so that the pointer dereference works properly

Am I correct ?

Thanks,
VJ