Windows上的文件处理例程

Question

是否允许在一个系统中混合使用不同的文件处理功能，例如

• 来自cstdio的fopen（）
• 来自fstream的open（）
• Win API中的CreateFile？

我有一个包含大量遗留代码的大型应用程序，似乎所有三种方法都在此代码中使用。什么是潜在的风险和副作用？

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代码，这可以使事情变得更容易。