不正確，凡是說這不能用那不能用的沒有原因的都是沙雕，只能說在什麼情況不適合用。網上最沙雕的就是還說某大公司規範啥儲存過程不能用。要是啥指令都不能用難道世界幾大公司都沙雕麼。造一堆不能用的玩意。

1.推薦儘量不用C艹。

2.流操作比格式化安全。

3.不用糾結這個細節，C艹的難點不是選cin還是scanf，能掌握，習慣，跟團隊合拍更重要。

4.繼續推薦不要用C艹，如果你還在糾結cin與scanf，那C艹真不適合你。

高效能高穩定性面前，這幾個都只能淪落為demo玩具。

最佳實踐是用輕量級物件編譯時抓捕不同型別的引數，構造格式化緩衝區發給後臺執行緒，然後立即返回，後臺執行緒生成格式化日誌寫入檔案，或者寫到控制檯，或者對型別引數進行動態檢查，或者用程式碼掃描工具進行掃描。

個人覺得正確的事說法是避免混用吧，cin cout為了跟標準輸入輸出同步會有一些額外的開銷，不混用的情況下可以使用ios:sync_with_stdio(false)來關掉，可以提升不少io效能，一般做程式設計競賽的時候會用到

本人是一個套著c++皮的c程式設計師，本人喜歡c++的面向物件，不喜歡c++標準庫的東西，什麼vector，list等，所以cin cout，不如scanf香的，它快啊。我們專案中進行比如向量運算時，直接在c++中寫彙編，simd指令不香嗎？c++標準庫就是浪費CPU的效率，什麼智慧指標，什麼模板，簡直編譯起來慢，執行起來更加慢，所以linus噴c++是有道理的。但是本人喜歡c++的class，裡面的public，protected，和private，這樣的許可權蠻香的。c++標準庫和那啥boost庫，我們組我是強烈不用的

再者說了，網上的人說話，我們通常都只能聽一聽，不能全信，尤其牽扯到你職業生涯以及人生生涯大是大非，更是要擦亮你的眼睛去分辨它的真偽，可能在某些個別人看來他是完全可以套用的，但上帝創造了我們人類，每個人都有他自己存在的特點，住進他與其他人是不同的，可能別的人看來這完全是正確的一個正確的事情，換了另一個人，他就完全是錯誤的。

我這裡並不是說抨擊網上的說這些話的人，可能說的人在他說這個話的時候，並沒有想到其他人的一個情況，只是根據自己的一個開發情況，常熟自己的一個具體狀況，言盡於此。

作為一位主要使用C/C++做開發的老碼農，我可以很肯定的回答這當然是一種不正確的做法，並不是這兩種方案熟好熟壞，而是取決於程式的設計方法，下面詳細說說原因。

首先需要理清cin、cout、fstream與scanf、printf、FILE*之間的關係。前者用來在C++進行流相關的操作，其中fstream是一個檔案流，當然還有其它型別的流，而cin和cout是兩個物件，用來進行輸入輸出操作。後者主要是C語言中的概念，其中scanf和printf是輸入輸出函式，而FILE是一個結構體。雖然後者也能在C++中使用，畢竟C++將C語言當作一個完全支援的子集，但是從程式設計的角度來講卻有著巨大的差別。

C++是一種支援面向物件程式設計的語言，如果以面向物件作為程式設計的基本方法，那麼使用類和物件等面向物件程式設計的技術才是正道，而流就是C++對檔案操作的一種具體實現，當然應該使用cin、cout、fstream等進行檔案操作。

當然，C++也支援面向過程的開發方法，而且和C語言完美相容，如果為了相容C程式，或者就是將C++當作C語言使用，那麼使用scanf和printf等函式操作，也是一種可選方案，而在這種方案中則要儘量避免使用面向物件的東西。

所以從理論上來說，具體使用那種方案，取決於你的程式設計選擇什麼樣的方法論，如果是面向物件就是用流操作；相反，如果為了相容C程式而使用面向過程設計，那麼就使用基本的函式操作。

總之，只要是語言本身支援的功能，如何使用都是可行的，但是要想使軟體的設計方案更完美，就需要遵循一定的規則，而這並沒有一個統一的標準，具體選擇哪種方案取決於實際應用，但是選擇統一的設計方法會給軟體開發帶來諸多好處。