gpt4 book ai didi

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

转载 作者:行者123 更新时间:2023-12-04 10:50:58 25 4
gpt4 key购买 nike

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

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

那么,您有什么特别的理由不想这样做吗?

这样的代码是否出于某种原因不可移植?

我意识到这种方法只适用于共享明确命名的函数和绑定(bind)函数,但对于加载一个插件,就我而言这很好...?

标题.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 的系统。这应该已经暗示你正在做的事情已经通过测试而不是遵循一些严格的标准文档来工作。因此,您可以移植到“无论它适用于什么”。

关于c - 从共享/动态库加载符号表结构的可移植性如何?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13375523/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com