Windows 上的文件处理例程
是否允许在一个系统中混合不同的文件处理函数，例如
- fopen() 中的 cstdio
- open() 中的 fstream
- CreateFile 中的 Win API ？
我有一个带有大量遗留代码的大型应用程序，并且似乎在该代码中使用了所有三种方法。潜在的风险和副作用是什么？
Is it allowed to mix different file handling functions in a one system e.g.
- fopen() from cstdio
- open() from fstream
- CreateFile from Win API ?
I have a large application with a lot of legacy code and it seems that all three methods are used within this code. What are potential risks and side effects ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的，您可以将所有这些混合在一起。无论如何，这一切都归结为 CreateFile 调用。
当然，您不能将文件指针传递给
CloseHandle并期望它能够工作，也不能期望从CreateFile打开的句柄与fclose< /代码>。其思考方式与 C++ 中的
malloc/free与new/delete完全相同。只要不混合使用，就完全可以同时使用。Yes, you can mix all of that together. It all boils down to the CreateFile call in any case.
Of course, you can't pass a file pointer to
CloseHandleand expect it to work, nor can you expect a handle opened fromCreateFileto work withfclose.Think of it exactly the same way you think of
malloc/freevsnew/deletein C++. Perfectly okay to use concurrently so long as you don't mix them.使用所有这些文件方法是完全可以的，只要它们不需要交互。当您需要将使用一种方法打开的文件传递给采用不同方法的函数时，您会发现它们不兼容。
作为一种风格问题，我建议选择一个并坚持使用它，但如果代码来自多个来源，那可能是不可能的。更改现有代码将是一项巨大的重构工作，而且没有太多收获。
It is perfectly OK to use all of these file methods, as long as they don't need to interact. The minute you need to pass a file opened with one method into a function that assumes a different method, you'll find that they're incompatible.
As a matter of style I would recommend picking one and sticking to it, but if the code came from multiple sources that may not be possible. It would be a big refactoring effort to change the existing code, without much gain.
你的情况并不少见。
设计为可移植的代码通常是使用标准文件访问例程（
fopen、open等）编写的。特定于操作系统的代码通常是使用该操作系统的本机 API 编写的。您的大型应用程序很可能是这两种类型的代码的组合。只要您记得保持它们的一致性（它们不可互换），在同一程序中混合文件访问样式应该没有问题。这里涉及的最大风险可能是可移植性。如果您有已经存在一段时间的遗留代码，它可能使用标准 C/C++ 文件访问方法，特别是如果它早于 Win32 API。使用 Win32 API 是可以接受的，但您必须意识到您正在将代码绑定到该 API 的范围和生命周期。您必须做额外的工作才能将该代码移植到另一个平台。例如，如果将来 Microsoft 废弃 Win32 API 以支持新的东西，您还必须重新编写此代码。标准的 C/C++ 方法将永远存在，恒定且不变。如果您想帮助您的代码面向未来，请尽可能坚持标准方法和函数。同时，有些事情需要Win32 API，并且无法使用标准函数来完成。
如果您正在使用 C 风格、C++ 风格和 Win32 风格代码的混合，那么我建议将您的操作系统特定代码和可移植代码分离（尽可能合理地）到单独的模块中，并使用以下命令：定义的 API。如果您将来必须重新编写 Win32 代码，这可以使事情变得更容易。
Your situation isn't that uncommon.
Code that is designed to be portable is usually written using standard file access routines (
fopen,open, etc). Code that is OS-specific is commonly written using that OS's native API. Your large application is most likely a combination of these two types of code. You should have no problem mixing the file access styles in the same program as long as you remember to keep them straight (they are not interchangeable).The biggest risk involved here is probably portability. If you have legacy code that has been around for a while, it probably uses the standard C/C++ file access methods, especially if it pre-dates the Win32 API. Using the Win32 API is acceptable, but you must realize that you are binding your code to the scope and lifetime of that API. You will have to do extra work to port that code to another platform. You will also have to re-work this code if, say, in the future Microsoft obsoletes the Win32 API in favor of something new. The standard C/C++ methods will always be there, constant and unchanging. If you want to help future-proof your code, stick to standard methods and functions as much as possible. At the same time, there are some things that require the Win32 API and can't be done using standard functions.
If you are working with a mix of C-style, C++-style, and Win32-style code, then I would suggest separating (as best as is reasonably possible) your OS-specific code and your portable code into separate modules with well-defined APIs. If you have to re-write your Win32 code in the future, this can make things easier.