TITLE: why no "inheritance" of assignment operator

[ This is a standard question I always ask of job applicants.
  The assignment operator is not "inherited", but the compiler
  will generate one for you if you do not explicitly have one.
  This generated one will automatically call any existing base
  class versions for you. -adc ]

(Newsgroups: comp.lang.c++.moderated)


PROBLEM: AshleyB@halcyon.com (Ashley Branchfeather)

I know what you're thinking, why would you ever want assignment to a
derived class to use a base class's assignment function? Well, if the
derived class adds no data members, but merely modifies the behaviour of
the base in some way, the base class assign may be sufficient. ...

1. Why did the designers of C++ make this decision? They _deliberately
made an exception_. Why? It seems completely pointless and it's very
frustrating.

My best guess is that someone said, "well, an assignment operator is a bit
like a constructor, and you can't inherit constructors, so you shouldn't
be able to inherit assignment operators either".

2. Is there a nice clean workaround that doesn't require declaring assign
operators for each derived class?

3. Will this be fixed in some future version of C++, or in some successor
to the language (C+=2) ?


RESPONSE: clamage@Eng.Sun.COM (Steve Clamage), 24 Jun 96

Assignment IS special. Assignment and copy construction are the only
operations predefined for all classes. (Assignment must be predefined
for compatibility with C.) Operator+= is not predefined for any class.
If you write (a+=b) it won't compile unless a programmer-defined operator+=
is available. 

Suppose operator= were inherited. If any base class anywhere in a hierarchy
had an operator=, you would have to be sure to define one in every
derived class that added any data, or even in some that didn't, to avoid
ambiguity in the presence of multiple inheritance. If the owner of some
base class added an operator=, your code could continue to compile while
quietly doing the wrong thing by default (inheriting an inappropriate
operator=).

OK, we don't want to inherit every operator=. Could we still say that
X::operator=(const X&) is created by the compiler, and inherit any
others? The problem with that is making different special cases. The
uniform overloading rules prevent overloading across scopes. A function
f in a derived class never overloads an f in a base class.

If you want derived::f to overload base::f, you have to say so explicitly
by putting a declaration of some sort in the derived class. Under
traditional C++ rules, you need a "forwarding function" in the 
derived class that calls the base-class version. Example:
	class base { ... int f(int); };
	class derived : public base {
		...
		int f(int i) { return base::f(i); } // forwarding function
		char* f(char*); // new overload
	};

Under new C++ rules, a using-declaration can bring base class functions
into the scope of the derived class, eliminating forwarding functions:

	class derived : public base {
		using base::f; // all versions of base::f now also in this scope
		char* f(char*); // new overload
	};

I think the using-declaration will take care of your problem without
adding any run time overhead to your program.