儘量用而不用

 是的，scanf和printf很輕巧，很高效，你也早就知道怎麼用它們，這我承認。但
儘管他們很有用，事實上scanf和printf及其系列還可以做些改進。尤其是，他們
不是類型安全的，而且沒有擴展性。因爲類型安全和擴展性是C++的基石，所以你
也要服從這一點。另外，scanf/printf系列函數把要讀寫的變量和控制讀寫格式的
信息分開來，就象古老的FORTRAN那樣。是該向五十年代說訣別的時候了！

不必驚奇，scanf/printf的這些弱點正是操作符>>和<<的強項:


int i;
Rational r;// r 是個有理數

...

cin >> i >> r;
cout << i << r;

上面的代碼要通過編譯，>>和<<必須是可以處理Rational類型對象的重載函數(可
能要通過隱式類型轉換)。如果沒有實現這樣的函數，就會出錯(處理int不用這樣
做，因爲它是標準用法)。另外，編譯器自己可以根據不同的變量類型選擇操作符
的不同形式，所以不必勞你去指定第一個要讀寫的對象是int而第二個是Rational
。

另外，在傳遞讀和寫的對象時採用的語法形式相同，所以不必象scanf那樣死記一
些規定，比如如果沒有得到指針，必須加上地址符，而如果已經得到了指針，又要
確定不要加上地址符。這些完全可以交給C++編譯器去做。編譯器沒別的什麼事好
做的，而你卻不一樣。最後要注意的是，象int這樣的固定類型和象Rational這樣
的自定義類型在讀寫時方式是一樣的。而你用sacnf和printf試試看！

你所寫的表示有理數的類的代碼可能象下面這樣：


class Rational {
public:
        Rational(int numerator = 0, int denominator = 1);
        
        ...
        
private:
        int n, d;// 分子，分母
        friend ostream& operator<<(ostream& s, const Rational& );
};

ostream& operator<<(ostream& s, const Rational& r)
{
        s<< r.n << '/' << r.d;
        return s;
}

上面的代碼涉及到operator<<的一些微妙(但很重要)的用法，這在本書其他地方詳
細討論。例如：上面的operator<<不是成員函數(條款19解釋了爲什麼)，而且，傳
遞給operator<<的不是Rational對象，而是定義爲const的對象的引用(參見條款
22)。operator>>的聲明和實現也類似。

儘管我不大願意承認，可有些情況下回到那些經過證明而且正確的老路上去還是很
有意義的。第一，有些iostream的操作實現起來比相應的C stream效率要低，所以
不同的選擇會給你的程序有可能(雖然不一定，參見條款M16)帶來很大的不同。但
請牢記，這不是對所有的iostream而言，只是一些特殊的實現；參見條款M23。第
二，在標準化的過程中，iostream庫在底層做了很多修改(參見條款49)，所以對那
些要求最大可移植性的應用程序來說，會發現不同的廠商遵循標準的程度也不同。
第三，iostream庫的類有構造函數而<stdio.h>裏的函數沒有，在某些涉及到靜態
對象初始化順序的時候，如果可以確認不會帶來隱患，用標準C庫會更簡單實用。

iostream庫的類和函數所提供的類型安全和可擴展性的價值遠遠超過你當初的想象
，所以不要僅僅因爲你用慣了<stdio.h>而捨棄它。畢竟，轉換到iostream後，你
也不會忘掉<stdio.h>。

順便說一句，本條款的標題沒有打印錯；我確實說的是<iostream>而非
<iostream.h>。從技術上說，其實沒有<iostream.h>這樣的東西——標準化委員會
在簡化非C標準頭文件時用<iostream>取代了它。他們這樣做的原因在條款49進行
瞭解釋。還必須知道的是，如果編譯器同時支持 <iostream>和<iostream.h>，那
頭文件名的使用會很微妙。例如，如果使用了#include <iostream>, 得到的是置
於名字空間std(見條款28)下的iostream庫的元素；如果使用#include 
<iostream.h>，得到的是置於全局空間的同樣的元素。在全局空間獲取元素會導致
名字衝突，而設計名字空間的初衷正是用來避免這種名字衝突的發生。還有，打字
時<iostream>比<iostream.h>少兩個字，這也是很多人用它的原因。:)