c-从共享/动态库加载符号表结构的可移植性如何



在windows和linux上,使用GetProcAddress()或dlsym()返回一个由函数指针填充的结构,以便从动态库中使用,这似乎很好。

但是,似乎有大量的人提出问题,抱怨将void指针转换为函数指针,并谈论使用dlfunc,而这种相对简单的方法似乎很有效。

那么,你不想这么做有什么特别的原因吗?

这样的代码是不是因为某种原因而不可移植?

我意识到这种方法只适用于共享显式命名的函数和绑定的函数,但对于加载插件,就我而言,这很好。。。?

header.h:

/* C++ safety & windows support */
#ifdef __cplusplus
#if _WIN32 || _WIN64
#define __EXT extern "C" __declspec(dllexport)
#else
#define __EXT extern "C"
#endif
#else
#if _WIN32 || _WIN64
#define __EXT __declspec(dllexport)
#else
#define __EXT extern
#endif
#endif
struct a_sym_table {
int (* action) (int argc, char *argv[]);
};
__EXT struct a_sym_table liba_symbols;

来源:c:

int perform_action_lib_a(int argc, char *argv[]) {
int rtn = perform_action_lib_b() + perform_action_lib_c();
return(rtn);
}
struct a_sym_table liba_symbols = {
&perform_action_lib_a
};

编辑:为了清楚起见,显然加载符号的代码在不同的平台上会有所不同,但这种方法允许共享库可以移植到不同的平台,而不会发生更改。

这就是我所说的,当我问,你有理由不这么做吗?

我想知道的是,是否有充分的理由不为了的便携性而这样构建共享库

您正在访问共享库中的数据。这就是dlsym()的作用。动态链接器应该能够很好地处理通过库边界的函数指针。至少在类unix系统上是这样。我不了解Windows,但我可以想象,如果某些类型的指针有效,而其他类型的指针无效,那么很多事情都会崩溃。

当谈到可移植性时,您已经被限制在那些拥有"#if_WIN32|_WIN64"背后的东西或实现dlsym的系统中。这应该已经暗示了你所做的是通过测试而不是遵循一些严格的标准文档来实现的。所以你可以移植到"任何工作"。

最新更新