MSVC和mingw之间的接口二进制兼容吗?

时间:2011-05-22 10:42:25

标签: visual-c++ compiler-construction mingw calling-convention binary-compatibility

我正在开发一个库,允许其用户(驻留在同一进程中的其他库)交换数据缓冲区和流。该库必须可以从MSVC和mingw代码中使用(更多兼容性不会受到影响,但并非严格必要)。为了实现这一目标,核心功能应该从一个小的,与编译器兼容的接口提供,稍后可以通过使用客户端代码编译的便利层来隐藏。

库的一个具有挑战性的方面是它必须是可扩展的,以便客户端可以提供自己的缓冲区和流实现,但核心库接口在发布后必须保持稳定。如果您对更多背景感兴趣,可以在forum thread discussion

中阅读相关内容

我试图了解编译器之间二进制兼容性的问题,但由于我是这个主题的新手,我会对我的结果发表评论。我对这里的标准定义行为不感兴趣(结构可能无法通过该测试),只有mingw和MSVC之间的兼容性以及可能其他编译器(如果方便的话)。

特别是,结构是否兼容?它们统一由函数指针组成,因此我认为填充不会成为问题。另外,这里需要stdcall约定,还是cdecl也能正常工作?我可以不指定它,因为两个编译器都默认为cdecl吗?我是不是该?这就是我现在所拥有的:

#include <stdint.h>

typedef struct {
        uint32_t (__stdcall *read)(void*, uint8_t*, uint32_t);
        void (__stdcall *write)(void*, const uint8_t*, uint32_t);
        uint32_t (__stdcall *getBytesLeft)(void*);
        uint8_t (__stdcall *destroy)(void*);
} SharedStreamInterface;

typedef struct {
        uint32_t (__stdcall *read)(void*, uint8_t*, uint32_t);
        void (__stdcall *write)(void*, const uint8_t*, uint32_t);
        uint32_t (__stdcall *getBytesLeft)(void*);
        uint8_t (__stdcall *destroy)(void*);

        uint32_t (__stdcall *getreadpos)(void*);
        uint32_t (__stdcall *getwritepos)(void*);
        uint32_t (__stdcall *getlength)(void*);
        void (__stdcall *setreadpos)(void*, uint32_t);
        void (__stdcall *setwritepos)(void*, uint32_t);
        void (__stdcall *setlength)(void*, uint32_t);
} SharedBufferInterface;

extern "C" {
        // Functions applicable for both buffers and streams
        __stdcall uint32_t readData(uint32_t id, uint8_t* data, uint32_t size);
        __stdcall void writeData(uint32_t id, const uint8_t* data, uint32_t size);
        __stdcall uint32_t getBytesLeft(uint32_t id);
        __stdcall void destroyStreamOrBuffer(uint32_t id);
        __stdcall uint8_t streamOrBufferExists(uint32_t id);

        // Functions only applicable for buffers
        __stdcall uint32_t getReadPos(uint32_t id);
        __stdcall uint32_t getWritePos(uint32_t id);
        __stdcall uint32_t getLength(uint32_t id);
        __stdcall void setReadPos(uint32_t id, uint32_t pos);
        __stdcall void setWritePos(uint32_t id, uint32_t pos);
        __stdcall void setLength(uint32_t id, uint32_t length);
        __stdcall uint8_t bufferExists(uint32_t id);

        // Adding new buffers/Streams
        __stdcall uint32_t addStream(SharedStreamInterface *interface, void *stream);
        __stdcall uint32_t addBuffer(SharedBufferInterface *interface, void *buffer);
}

编辑:这个项目的目的已暂停了一段时间,如果它再次没有得到解决,可能需要进行大量的重新思考。我离开了这个问题,因为我仍然对答案感兴趣。

1 个答案:

答案 0 :(得分:3)

是的,它们兼容。这就是struct的美丽。只要你没有引入填充问题(这在你正确指出的情况下确实不是这种情况),或者在C ++中添加将导致的struct功能 - 特定于编译器 - vtable布局,这将始终兼容。

您还会注意到,从Windows标头中,COM接口的C声明使用struct的方式与您的方式非常相似。

旁注:SharedStreamInterface::destroy成员提出了是否还有一个“创建”此类流的问题。您可能也想分享它。但你的里程可能会有所不同......

至于调用约定的问题,__cdecl__stdcall 都应该跨二进制文件工作,但是我总是更喜欢__stdcall的另一个原因:它与__cdecl以上的“语言”(即工具)兼容。

对于样式:使用#define显式声明调用约定(与您一样),类似于Windows标题中的WINAPI