算符重載的作用是什麼？它允許你為類的用戶提供一個直覺的接口。 算符重載允許C/C++的運算符在用戶定義類型（類）上擁有一個用戶定義的意義。重載的算符是函數調用的語法修飾：
class Fred {
public: // …
};
#if 0 // 沒有算符重載：
Fred add(Fred, Fred);
Fred mul(Fred, Fred);
Fred f(Fred a, Fred b, Fred c)
{
return add(add(mul(a,b), mul(b,c)), mul(c,a)); // 哈哈，多可笑…
}
#else // 有算符重載：
Fred operator+ (Fred, Fred);
Fred operator* (Fred, Fred);
Fred f(Fred a, Fred b, Fred c)
{
return a*b + b*c + c*a;
}
#endif
算符重載的好處是什麼？
通過重載類上的標准算符，你可以發掘類的用戶的直覺。使得用戶程序所用的語言是面向問題的，而不是面向機器的。 最終目標是降低學習曲線並減少錯誤率。
有什麼算符重載的實例？這裡有一些算符重載的實例：
myString + yourString 可以連接兩個 std::string 對象
myDate++ 可以增加一個 Date 對象
a * b 可以將兩個 Number 對象相乘
a[i] 可以訪問 Array 對象的某個元素
x = *p 可以反引用一個實際“指向”一個磁盤記錄的 "smart pointer" —— 它實際上在磁盤上定位到 p 所指向的記錄並返回給x。
但是算符重載使得我的類很丑陋；難道它不是應該使我的類更清晰嗎？算符重載使得類的用戶的工作更簡易，而不是為類的開發者服務的！ 考慮一下如下的例子：
class Array {
public:
int& operator[] (unsigned i);
};
inline
int& Array::operator[] (unsigned i)
{ // …
}
有些人不喜歡operator關鍵字或類體內的有些古怪的語法。但是算符重載語法不是被期望用來使得類的開發者的工作更簡易。它被期望用來使得類的用戶的工作更簡易：
int main()
{
Array a;
a[3] = 4; // 用戶代碼應該明顯而且易懂…
}
記住:在一個面向重用的世界中，使用你的類的人有很多，而建造它的人只有一個（你自己）；因此你做任何事都應該照顧多數而不是少數。
什麼算符能／不能被重載？大多數都可以被重載。C的算符中只有 . 和 ? :（以及sizeof，技術上可以看作一個算符）。C++增加了一些自己的算符，除了::和.*，大多數都可以被重載。 這是一個下標算符的示例（它返回一個引用）。先沒有算符重載：
class Array {
public:
int& elem(unsigned i) { if (I > 99) error(); return data[i]; }
private:
int data[100];
};
int main()
{
Array a;
a.elem(10) = 42;
a.elem(12) += a.elem(13);
}
現在用算符重載給出同樣的邏輯：
class Array {
public:
int& operator[] (unsigned i) { if (I > 99) error(); return data[i]; }
private:
int data[100];
};
int main()
{
Array a;
a[10] = 42;
a[12] += a[13];
}
我能重載 operator== 以便比較兩個 char[] 來進行字符串比較嗎？不行：被重載的算符，至少一個操作數必須是用戶定義類型（大多數時候是類）。 但即使C++允許，也不要這樣做。因為在此處你應該使用類似 std::string的類而不是字符數組，因為數組是有害的。因此無論如何你都不會想那樣做的。
我能為“冪”運算創建一個 operator** 嗎？不行。 運算符的名稱、優先級、結合性以及元數都是由語言固定的。在C++中沒有operator**，因此你不能為類類型創建它。
如果還有疑問，考慮一下x ** y與x * (*y)等同（換句話說，編譯器假定 y 是一個指針）。此外，算符重載只不過是函數調用的語法修飾。雖然這種特殊的語法修飾非常美妙，但它沒有增加任何本質的東西。我建議你重載pow(base,exponent)（雙精度版本在中）。
順便提一下，operator^可以成為冪運算，只是優先級和結合性是錯誤的。
如何為Matrix（矩陣）類創建下標運算符？ [Recently changed so it uses new-style headers and the std:: syntax (on 7/00). Click here to go to the next FAQ in the "chain" of recent changes.]
用 operator()而不是operator[]。
當有多個下標時,最清晰的方式是使用operator()而不是operator[]。原因是operator[]總是帶一個參數，而operator()可以帶任何數目的參數（在矩形的矩陣情況下，需要兩個參數）。
如：
class Matrix {
public:
Matrix(unsigned rows, unsigned cols);
double& operator() (unsigned row, unsigned col);
double operator() (unsigned row, unsigned col) const; // …
Matrix(); // 析構函數
Matrix(const Matrix& m); // 拷貝構造函數
Matrix& operator= (const Matrix& m); // 賦值算符 // …
private:
unsigned rows_, cols_;
double* data_;
};
inline
Matrix::Matrix(unsigned rows, unsigned cols)
: rows_ (rows),
cols_ (cols),
data_ (new double[rows * cols])
{
if (rows == 0 || cols == 0)
throw BadIndex("Matrix constructor has 0 size");
}
inline
Matrix::~Matrix()
{
delete[] data_;
}
inline
double& Matrix::operator() (unsigned row, unsigned col)
{
if (row >= rows_ || col >= cols_)
throw BadIndex("Matrix subscript out of bounds");
return data_[cols_*row + col];
}
inline
double Matrix::operator() (unsigned row, unsigned col) const
{
if (row >= rows_ || col >= cols_)
throw BadIndex("const Matrix subscript out of bounds");
return data_[cols_*row + col];
}
然後，你可以使用m(I,j)來訪問Matrix m 的元素，而不是m[i][j]：
int main()
{
Matrix m(10,10);
m(5,8) = 106.15;
std::cout << m(5,8); // …
}
為什麼Matrix（矩陣）類的接口不應該象數組的數組？本FAQ其實是關於：某些人建立的Matrix 類，帶有一個返回 Array 對象的引用的operator[]。而該Array 對象也帶有一個 operator[] ，它返回Matrix的一個元素（例如，一個double的引用）。因此，他們使用類似m[i][j]的語法來訪問矩陣的元素，而不是象m(I,j)的語法。
數組的數組方案顯然可以工作，但相對於operator()方法來說，缺乏靈活性。尤其是，用[][]方法很難表現的時候，用operator()方法可以很簡單的完成，因此[][]方法很可能導致差勁的表現，至少某些情況細是這樣的。
例如，實現[][]方法的最簡單途徑就是使用作為密集矩陣的，以以行為主的形式保存（或以列為主，我記不清了）的物理布局。相反，operator() 方法完全隱藏了矩陣的物理布局，在這種情況下，它可能帶來更好的表現。
可以這麼認為：operator()方法永遠不比[][]方法差，有時更好。
operator() 永遠不差，是因為用operator()方法實現以行為主的密集矩陣的物理布局非常容易。因此，當從性能觀點出發，那樣的結構正好是最佳布局時，operator()方法也和[][]方法一樣簡單（也許operator()方法更容易一點點，但我不想誇大其詞）。 Operator() 方法有時更好，是因為當對於給定的應用，有其它比以行為主的密集矩陣更好的布局時，用 operator() 方法比[][]方法實現會容易得多。 作為一個物理布局使得實現困難的例子，最近的項目發生在以列訪問矩陣元素（也就是，算法訪問一列中的所有元素，然後是另一列等），如果物理布局是以行為主的，對矩陣的訪問可能會“cache失效”。例如，如果行的大小幾乎和處理器的cache大小相當，那麼對每個元素的訪問，都會發生“cache不命中”。在這個特殊的項目中，我們通過將映射從邏輯布局（行，列）變為物理布局（列，行），性能得到了20%的提升。
當然，還有很多這類事情的例子，而稀疏矩陣在這個問題中則是又一類例子。通常，使用operator()方法實現一個稀疏矩陣或交換行／列順序更容易，operator()方法不會損失什麼，而可能獲得一些東西——它不會更差，卻可能更好。
使用 operator() 方法。
該從外（接口優先）還是從內（數據優先）設計類？從外部！ 良好的接口提供了一個簡化的，以用戶詞匯表達的視圖。在面向對象軟件的情況下，接口通常是單個類或一組緊密結合的類的public方法的集合. 首先考慮對象的邏輯特征是什麼，而不是打算如何創建它。例如，假設要創建一個Stack（棧）類，其包含一個 LinkedList：
class Stack {
public: // …
private:
LinkedList list_;
};
Stack是否應該有一個返回LinkedList的get()方法？或者一個帶有LinkedList的set()方法？或者一個帶有LinkedList的構造函數？顯然，答案是“不”，因為應該從外向裡設計接口。也就是說，Stack對象的用戶並不關心 LinkedList；他們只關心 pushing 和 popping。
現在看另一個更微妙的例子。假設 LinkedList類使用Node對象的鏈表來創建，每一個Node對象有一個指向下一個Node的指針：
class Node { /*…*/ };
class LinkedList {
public: // …
private:
Node* f
