operator overloading in c++

Operator overloading is a very essential element to perform the operations on user-defined data types. By operator overloading we can modify the default meaning to the operators like +, -, *, /, <=, etc. 
```
#include <iostream>
using namespace std;

class Complex{
private:
    float r, i;
public:
    Complex(float r, float i) {
        this->r = r;
        this->i = i;
    }
    void say() {
        cout << r << "+" << i << "i";
    }
    Complex operator+(Complex& c) {
        return Complex(r + c.r, i + c.i);
    }
};

int main() {
    Complex a(1,1), b(2,2);
    a = a+b;
    a.say();
    return 0;
}
```
Prefix doesn't take any parameter but postfix does. Why? The operator symbol for both prefix(++i) and postfix(i++) are the same. Hence, we need two different function definitions to distinguish between them. This is achieved by passing a dummy int parameter in the postfix version.
```
 class Number {
 public:
   Number& operator++ ();    // prefix ++
   Number& operator++ (int); // postfix ++
 }; 
```
C++ operators cannot be overloaded?
* There is no fundamental reason to disallow overloading of ?:. So far the committee just hasn’t seen the need to introduce the special case of overloading a ternary operator. 
* sizeof cannot be overloaded because built-in operations, such as incrementing a pointer into an array implicitly depends on it. Thus, sizeof(X) could not be given a new and different meaning by the programmer without violating basic language rules.
* In N::m neither N nor m are expressions with values; N and m are names known to the compiler and :: performs a (compile time) scope resolution rather than an expression evaluation. One could imagine allowing overloading of x::y where x is an object rather than a namespace or a class, but that would – contrary to first appearances – involve introducing new syntax (to allow expr::expr). It is not obvious what benefits such a complication would bring.
* operator. (dot) could in principle be overloaded using the same technique as used for ->. However, doing so can lead to questions about whether an operation is meant for the object overloading . or an object referred to by .