原因有幾點:
首先,算法競賽是考算法的,輸入輸出只需要使用一種通用的方式即可,不需要特意去「考」其它的方式。
在競賽中,輸入/輸出文件是需要機器與人共同處理的部分,需要「既能讓程序無歧義解析,也能讓人直接瀏覽和編輯」的(即所謂的 human-readable 格式)。其中文本格式對電腦環境和軟件工具的依賴最小,自然是達成這個目標的首選。而在現實應用中,軟件的用戶配置文件如 conf、ini、xml 等也都如此。
過去所謂的「Unix 哲學」提出程序間應當使用文本流輸入輸出也是考慮了「人」在其中的作用。(一定程度上也是因為當時的電腦除了命令行和文本編輯器外也沒有什麼其他好用的工具,甚至連十六進制編輯也不是什麼方便的事)
而 程序文件、打包或壓縮的數據、媒體數據、程序內部數據、僅用於程序間交互(如 數據庫)或機器間交互的數據(如網絡傳輸協議)、不希望用戶直接編輯的數據(如遊戲存檔)等場合才是二進制大行其道的。
至於「為什麼不教 read 系列的快速輸入方法」嘛…雖然 read 作為系統調用確實快速,但它更適合將已知長度的純二進制數據讀入 struct 或 array 之類的,以及用 read 讀字符串也不會給你補 '\0'(速度沒差多少的 get 系列方法則沒這問題)。所以其天生與文本格式且字節數一般不能預先確定的 human-readable 不合。此外,競賽中這個所謂的「優化」不僅多數場合聊勝於無,還會令輸入部分的代碼加長,擠壓寶貴的比賽時間。實際真的遇到大規模輸入的時候,學會用 fgets 才是更有效的手段。