c++ - 我可以跨 DLL 边界传递 FILE 对象吗？

Question

我有一个 C++ 框架，其中一些计算被委托(delegate)给(有时是自动生成的)C 函数或具有外部“C”链接的 C++ 函数。这些是低级例程，必须以极快的速度和最小的开销进行评估，它们通常驻留在单独的共享对象/DLL 中。他们目前的签名是这样的:

int my_generated_function(const double* input, double* output, double* work);

它将驻留在共享库中，在 POSIX 上使用 dlopen 或在 Windows 上使用 LoadLibrary 加载。在 POSIX 上使用 dlsym(handle, "my_generated_function") 或在 Windows 上使用 GetProcAddress(handle, TEXT("my_generated_function")) 提取相应的函数指针。

使用 FILE 对象指针扩充签名是否安全且可移植？

int my_generated_function(const double* input, double* output, double* work,
                          FILE* logfile);

请注意，包含 my_generated_function 的共享对象可能是使用与加载共享对象的代码不同(但二进制兼容)的编译器编译的。

Answer 1

你可以想到FILE*作为一个不透明的句柄。问题在于此句柄下的实际对象，换句话说，FILE 结构的定义及其实现细节，是特定于编译器/CRT 的。

因此，据我所知，不能保证 FILE 实现例如Visual Studio 2008 或 2010 与 VS2015 或 2017 中的相同。换句话说，即使结构(FILE)的名称相同，实现细节也可能发生很大变化从一个版本的 CRT 到另一个版本。

所以，我建议不要 FILE*在 DLL 边界，除非您想限制您的客户端使用 相同 版本的 VC++ 编译器/CRT。

另一方面，如果您在 DLL 接口(interface)边界需要一个交叉编译器/CRT 兼容句柄，我建议使用 Win32 HANDLE类型(从 CreateFile 等 API 返回的类型)。这是在操作系统级别定义的，因此它独立于特定的 VC++ 编译器/CRT。

如果你想获得 Win32 HANDLE来自FILE* , 你可以使用 _get_osfhandle与 _fileno ，如 this SO answer 中所述.