Windows上的文件處理例程

Question

是否允許在一個系統中混合不同的文件處理函數，例如

• 從cstdio從贏API從fstream的
• 的open（）
• 的CreateFile fopen（）函數？

我有一個很大的應用程序，有很多遺留代碼，似乎在這個代碼中使用了所有三種方法。什麼是潛在風險和副作用？

Answer 1

是的，你可以混合在一起。無論如何，這都歸結爲CreateFile調用。

當然，您不能將文件指針傳遞給CloseHandle並期望它可以正常工作，也不能期望從CreateFile打開的句柄可以與fclose一起使用。

想象一下，您在C++中的想法與您想到的malloc/free vs new/delete完全相同。完全可以同時使用，只要不混合即可。

Answer 2

只要它們不需要交互，使用所有這些文件方法是完全可以的。只需將用一種方法打開的文件傳遞給採用其他方法的函數，您就會發現它們不兼容。

作爲一種風格，我會建議選擇一個並堅持下去，但如果代碼來自多個來源，可能是不可能的。改變現有代碼將是一個很大的重構努力，沒有太大的收穫。

Answer 3

你的情況並不罕見。

設計爲可移植的代碼通常使用標準文件訪問例程編寫（fopen,open等）。代碼是特定於操作系統的，通常使用該操作系統的本地API編寫。您的大型應用程序很可能是這兩種代碼類型的組合。只要你記得讓它們保持直線（它們不能互換），你應該在同一個程序中混合使用文件訪問風格。

這裏涉及的最大風險可能是可移植性。如果您的遺留代碼已經存在了一段時間，那麼它可能會使用標準的C/C++文件訪問方法，尤其是在它預先計劃Win32 API的情況下。使用Win32 API是可以接受的，但是你必須認識到你將代碼綁定到該API的範圍和生命週期。您將不得不做額外的工作將該代碼移植到另一個平臺。如果未來微軟將Win32 API廢棄爲支持新功能，那麼您還必須重新編寫此代碼。標準的C/C++方法將永遠存在，不變且不變。如果你想幫助未來的代碼，儘可能的使用標準的方法和函數。同時，有些事情需要Win32 API，並且不能使用標準函數完成。

如果您正在使用混合使用C風格，C++風格和Win32風格的代碼，那麼我會建議將您的操作系統特定代碼和可移植代碼分離（儘可能合理）具有定義良好的API的模塊。如果將來必須重新編寫Win32代碼，這可以讓事情變得更簡單。