FILE* 的二进制兼容性
我正在设计 C 库，它可以进行一些数学计算。我需要指定序列化接口才能保存然后加载一些数据。问题是，在库的公共 API 中使用 FILE* 指针是否正确（从二进制兼容性的角度来看）？
目标平台是：
- Linux x86, x86_64 with gcc >= 3.4.6
- Windows x86, x86_64 >= WinXP with VS >= 2008sp1
我需要尽可能多的二进制兼容，所以目前我的变体是以下：
void SMModuleSave(SMModule* module, FILE* dest);
SMModule* SMModuleLoad(FILE* src);
所以我很好奇使用 FILE* 是否正确或更好地切换到 wchar*/char* ？
I am designing C library which does some mathematical calculations. I need to specify serialization interface to be able to save and then load some data. The question is, is it correct (from binary compatibility point of view) to use FILE* pointer in the public API of library?
Target platfoms are:
- Linux x86, x86_64 with gcc >= 3.4.6
- Windows x86, x86_64 >= WinXP with VS >= 2008sp1
I need to be as much binary compatible as it possible, so at the moment my variant is the following:
void SMModuleSave(SMModule* module, FILE* dest);
SMModule* SMModuleLoad(FILE* src);
So I am curious if it is correct to use FILE* or better switch to wchar*/char* ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我不同意 ThiefMaster 的观点：当存在等效的便携式解决方案。
我可能会使用 FILE * ，而不是从库中按名称打开文件：这对于库用户来说可能会更麻烦，但它也更灵活，因为大多数 libc 实现都提供了各种方式用于打开文件（
fopen()、_wfopen()、_fdopen()、fdopen()、fmemopen(),...) 并且您不必自己维护单独的宽字符 API。I don't agree with ThiefMaster: there's no benefit in going native (ie using file descriptors of type
inton linux and handles of typevoid *on windows) when there's an equivalent portable solution.I'd probably go with
FILE *instead of opening the files by name from within the library: It might be more of a hassle for library users, but it's also more flexible as most libc implementations provide various ways for file opening (fopen(),_wfopen(),_fdopen(),fdopen(),fmemopen(),...) and you don't have to maintain seperate wide-char APIs yourself.我不会使用任何一个，而是让用户将文件描述符作为
int传递。然后您可以在代码中使用
fdopen()来获取FILE*。然而，当使用 Windows 时，即使它确实有一些辅助函数来获取数字文件描述符，它也可能不是最好的解决方案。
但是，传递
FILE*或const char*也应该没问题。我更喜欢传递文件名，因为如果库负责打开/关闭文件，则需要编写的代码更少。I'd use neither but let the user pass a file descriptor as an
int.Then you can
fdopen()it in your code to get aFILE*.However, when using windows it might not be the best solution even though it does have some helper functions to get a numeric file descriptor.
However, passing a
FILE*or aconst char*should be fine, too. I'd prefer passing a filename as it's less code to write if a library takes care of opening/closing a file.是的，从稳定的二进制接口的角度来看，在这里使用
FILE *是正确的。我想您可能会将其与使用FILE而不是指向它的指针混淆。请注意，标准库的fopen、fgets等函数都使用（作为参数和返回值）FILE *类型作为他们的公共接口。Yes it is correct, from a stable binary interface perspective, to use
FILE *here. I think perhaps you're confusing this with usingFILEas opposed to a pointer to it. Notice that your standard library'sfopen,fgets, etc. functions all use (both as arguments and return values) theFILE *type as part of their public interfaces.FILE *是标准 ANSI/ISO C89 和 C99（甚至 K&R）类型。这是一个便携性的梦想，我更喜欢它。你可以安全地接受它。没有比这更好的了。A
FILE *is a standard ANSI/ISO C89 and C99 (even K&R) type. It is a portability dream and I'd prefer it over anything else. You're safe to go with it. It won't get any better than that.