8

Why is overloaded operator= mandated to be a member function ($13.5.3), but not a compound assignment operator e.g. operator+= ($13.5.2)? Am I overlooking something here?

Chubsdad
  • 24,777
  • 4
  • 73
  • 129
  • possible duplicate of [Why friend function can't be used for overloading assignment operator ?](http://stackoverflow.com/questions/3933637/why-friend-function-cant-be-used-for-overloading-assignment-operator) – Armen Tsirunyan Nov 16 '10 at 09:52

4 Answers4

4

A copy assignment operator=, as a member, is always provided by the compiler if the user doesn't define one. I believe that it was only for simplicity and to avoid unexpected ambiguities that it was made a requirement that operator= can't be defined as a free function.

Conversion operators take care of the case when you want to assign from a user-defined type to a built-in type.

CB Bailey
  • 755,051
  • 104
  • 632
  • 656
  • So my question I guess now is why certain operators are mandated to be overloaded as members e.g. operator [], operator() while others are not? – Chubsdad Nov 16 '10 at 09:34
  • 1
    @Chubsdad, no that's not your question, that's another question, feel free to answer it but Charles (and others) have answered _this_ question. – Motti Nov 16 '10 at 09:37
  • @Motti: Not sure if this happens to you or not, but it happens to me at least. While discussing and sharing, a lot more clarity emerges about what one wants – Chubsdad Nov 16 '10 at 09:38
  • 1
    @Chubsdad: stackoverflow.com has always been a Q & A site and very deliberately _not_ a discussion site. – CB Bailey Nov 16 '10 at 09:43
2

The sections you reference have this to say about hiding base class implementations of operator=

Because a copy assignment operator operator= is implicitly declared for a class if not declared by the user (12.8),

This may also be the answer to your question, since the compiler needs to know if it should generate an operator= it must know if such an operator was defined, if it could be defined outside the class the compiler couldn't know if it was defined in a different translation unit.

e.g. 

//a.h
class A { }; // compiler thinks A::operator= should be implicitly defined

//b.h
#include "a.h"
A& operator=(A& This, const A& other) { /*...*/ } // Oops it's explicitly defined

Compound operators, on the other hand, are not implicitly defined therefore there is no reason to force them to be declared as member functions.

Motti
  • 110,860
  • 49
  • 189
  • 262
1

Along with default and copy constructors, operator= is also treated specially in C++. That means, even if you don't declare one, the compiler will provide a default implementation for you. But default implementations are not always the behaviour that suits your class' needs, that's why you should declare them explicitly (or hide them, by assigning private visibility).

And why is default constructor, copy constructor and assignment operator so special? Because they are involved in standard variable initialization and parameter passing: when you pass a class-typed parameter to a function by value (not by reference or pointer), these operations are called to copy it's content to the stack.

buc
  • 6,268
  • 1
  • 34
  • 51
1

As stated by Charles, a copy assignment operator= is always provided by the compiler if the user doesn't define one. This compiler provided member function would always have precedence over a non-member function, so even if you could define it as a non-member function, it wouldn't be called.

icecrime
  • 74,451
  • 13
  • 99
  • 111