Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!ncrlnk!ncrcae!hubcap!gatech!bloom-beacon!tut.cis.ohio-state.edu!mailrus!cornell!patrick
From: patrick@cs.cornell.edu (Pat Stephenson)
Newsgroups: comp.lang.c++
Subject: Re: Bug in cfront 1.2.1.  operator= not inherited properly.
Summary: This is not a bug,
Message-ID: <21683@cornell.UUCP>
Date: 12 Oct 88 20:08:37 GMT
Article-I.D.: cornell.21683
Sender: nobody@cornell.UUCP
Reply-To: patrick@cs.cornell.edu (Pat Stephenson)
Organization: Cornell Computer Science
Lines: 36
In-reply-to: beshers@fork.columbia.edu (Clifford Beshers)


In article <5936@columbia.edu>, beshers@fork (Clifford Beshers) writes:
>//  The following code illustrates a bug in cfront 1.2.1
>//  The operator= member does not get inherited properly.
>//  It can be invoked with the syntax b.operator=(a), but not
>//  with b=a.
>

This is not a bug - at least not the way you think.  The C++ reference manual
states: (8.5.3, page 277):

        "Assignment is not implicitly defined (see 7.14 and 8.5) for objects
	of a class derived from a class for which "operator=" has been defined
	(8.5.11)."

7.14 says:

	"Object of some derived classes cannot be assigned; see 8.5.3"

On page 171, the book says:

	"  ... a use of the operator is only shorthand for an explicit call of
	the operator function"

I conclude that the real bug is that cfront allows "b.operator=(a)".

Pat

-------------------------------------------------------------------------------
Pat Stephenson					    Computer Science Department
pat@cs.cornell.edu					     Cornell University
607-255-8597							Ithaca NY 14850
--------------------------------------------------------------------------------
Pat Stephenson					     Computer Science Department
pat@cs.cornell.edu					      Cornell University
607-255-8597							 Ithaca NY 14850