Question

我有一个C ++框架，其中一些计算被委托（有时自动生成）C函数或C ++函数与外部＆＃34; C＆＃34;连锁。这些是低级例程，必须以非常快的速度进行评估并且开销最小，并且它们通常驻留在单独的共享对象/ 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到另一个版本。

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

另一方面，如果你需要DLL接口边界的交叉编译器/ CRT兼容句柄，我建议使用Win32 HANDLE类型（从{{3}返回的API类型}}）。这是在OS级别定义的，因此它独立于特定的VC ++编译器/ CRT。

如果您想从HANDLE获取Win32 FILE*，可以_get_osfhandle使用_fileno，CreateFile中说明。

我可以跨越DLL边界传递FILE对象吗？

1 个答案: