gpt4 book ai didi

c - 库的头文件中的结构定义和编译差异

转载 作者:太空狗 更新时间:2023-10-29 17:25:50 24 4
gpt4 key购买 nike

我有一段代码被编译成一个库(dll、静态库等)。我希望这个库的用户使用一些结构来传递一些数据作为库函数的参数。我考虑过在 API 头文件中声明结构。

  • 这样做是否安全,考虑到使用不同的编译器进行编译,关于结构对齐或其他我没有考虑过的事情?
  • 库及其用户是否需要使用相同的编译器(和标志)?

一些注意事项:

  1. 我考虑过给用户一个指针并通过库中的函数设置所有结构,但这会使 API 使用起来真的很不舒服。
  2. 这个问题是关于 C 的,尽管如果知道 c++ 中是否存在差异会很好。

最佳答案

如果是常规/静态库,则库和应用程序应使用相同的编译器进行编译。我能想到的有几个原因:

  1. 不同的编译器(如不同品牌或不同平台的编译器)通常不理解彼此的对象和库格式。
  2. 您不想使用不同的类型(例如 signed 与 unsigned char)、类型大小(例如 long = 32 与 64 位)、对齐和打包以及可能的其他一些东西来编译同一程序的不同部分,所有这些C标准允许改变。混合搭配这些东西通常是一件坏事。

但是,您可能经常使用同一编译器的稍微不同的版本来编译库和使用它的应用程序。通常,没关系。不过,有时会有破坏代码的更改。

您可以在该头文件中实现一些“初始化”函数(声明为 static inline),以确保类型、类型大小、对齐和打包与编译库所期望的相同。使用该库的应用程序必须在使用该库的任何其他部分之前调用该函数。如果事情与预期不一样,该函数必须失败并导致程序终止,可能有一些很好的失败文本描述。这不会完全解决编译器有些不兼容的问题,但它可以防止无声和神秘的故障。有些事情可以用预处理器的 #if#ifdef 指令检查,并用 #error 导致编译错误。

此外,可以通过在结构声明中插入显式填充字节并强制进行紧密打包(例如使用许多编译器都支持的#pragma pack)来缓解结构打包问题。这样,如果类型大小相同,则默认包装是什么都无关紧要。

您也可以将相同的方法应用于 DLL,但您确实应该期望调用应用程序是使用不同的编译器编译的,而不是依赖于相同的编译器。

关于c - 库的头文件中的结构定义和编译差异,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8549890/

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