1

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

  • 来自 cstdio 的 fopen()
  • 来自 fstream 的 open()
  • 来自 Win API 的 CreateFile ？

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

4

3 回答 3

2

是的，您可以将所有这些混合在一起。无论如何，这一切都归结为 CreateFile 调用。

当然，您不能将文件指针传递给CloseHandle并期望它可以工作，也不能期望打开的句柄CreateFile可以使用fclose.

与您在 C++ 中对malloc/ freevs new/的看法完全相同。delete完全可以同时使用，只要你不混合它们。

于 2010-07-07T15:31:44.133 回答
1

使用所有这些文件方法是完全可以的，只要它们不需要交互。当您需要将使用一种方法打开的文件传递给采用不同方法的函数时，您会发现它们不兼容。

作为风格问题，我建议选择一个并坚持下去，但如果代码来自多个来源，那可能是不可能的。更改现有代码将是一项巨大的重构工作，但没有太多收获。

于 2010-07-07T15:33:53.777 回答
1

你的情况并不少见。

设计为可移植的代码通常使用标准文件访问例程（fopen、、open等）编写。特定于操作系统的代码通常使用该操作系统的本机 API 编写。您的大型应用程序很可能是这两种代码的组合。只要您记得保持它们的正确性（它们不可互换），在同一个程序中混合文件访问样式应该没有问题。

这里涉及的最大风险可能是便携性。如果您有已经存在一段时间的遗留代码，它可能使用标准的 C/C++ 文件访问方法，尤其是在它早于 Win32 API 的情况下。使用 Win32 API 是可以接受的，但您必须意识到您将代码绑定到该 API 的范围和生命周期。您必须做额外的工作才能将该代码移植到另一个平台。如果将来 Microsoft 弃用 Win32 API 以支持新的东西，您还必须重新编写此代码。标准的 C/C++ 方法将始终存在，不变且不变。如果您想帮助您的代码经得起未来的考验，请尽可能坚持使用标准方法和功能。同时，有些事情需要Win32 API，而使用标准函数是无法做到的。

如果您正在使用 C 风格、C++ 风格和 Win32 风格代码的混合体，那么我建议您将特定于操作系统的代码和可移植代码分离（尽可能合理地）到单独的模块中定义的 API。如果您将来必须重新编写 Win32 代码，这可以使事情变得更容易。

于 2010-07-07T15:58:52.227 回答