简单的方法来保证C ++库和C链接的二进制兼容性? [英] Easy way to guarantee binary compatibility for C++ library, C linkage?
问题描述
我不知道确切的方法来保证Windows和Linux上C ++库的二进制兼容性. 但是我认为，如果我使所有公开的API都使用C链接，那么我可以轻松保证在Windows和Linux上的兼容性.
I don't know exact way to guarantee binary compatibility for C++ library on both Windows and Linux. But I think if I make all exposed APIs with a C linkage I think I can easily guarantee this compatibility on both Windows and Linux.
就像下面这样:
外部"C" int SomeAPI();
extern "C" int SomeAPI();
其他功能肯定会用C ++编写.只有暴露于外界的API才具有C链接.
Rest of the functions surely will be written in C++. Only the APIs exposed to outter world will have C linkage.
公开的API必须是纯C函数-不得例外，不使用任何C ++类型.
And the exposed API's must be pure C function - no exceptions, no C++ types are used.
我是对还是错? 我有什么误会吗?
Am I right or wrong? Do I have any misunderstandings?
我想即使是C程序，我也可以使用此库.
I think I can use this library even with C program also.
我要实现的兼容性是编译器前向兼容性和标准库前向兼容性.
The compatibility I'd like to achieve is compiler forward compatibility and standard library forward compatibility.
而且我不能将其开源.我只需要关闭它. ->我将尝试使其开源.
And I cannot make it opensource. I only have to close it. --> I will try making it open source.
我使用boost和STL制作共享或静态C ++库. 我也想知道该兼容性不仅适用于编译，还适用于在OS和OS中启动和运行.
I use boost and STL for making shared or static C++ library. Also I wonder the compatibility not only for compiling but also for launching and running in and OS.
我说得对吗?
推荐答案
For binary compatibility, what also matters is the application binary interface (ABI).
顺便说一句，C ++函数不仅可以返回一些结果，还可以引发一些异常.您需要对此进行记录(即使您决定不引发任何异常也很难实现，例如，因为 new 可以抛出
BTW, C++ functions can not only return some results, but also throw some exceptions. You need to document that (even if you decide that no exceptions are thrown, which is actually difficult to achieve, e.g. because new can throw std::bad_alloc and this can happen inside some internal layers of your software).
请注意(尤其是在Linux上)C ++标准库的ABI确实随着编译器的各种版本而改变.例如，std::string -s或标准C ++ 容器的实现确实有所不同(以一种微妙的不兼容的方式，在二进制级别).您可以静态链接C ++标准库(但这可能并不总是足够的，或者可能很脆弱，例如，如果用户程序还因为它的代码在C ++中而需要它的话).
Notice that (notably on Linux) the ABI of the C++ standard library did change with various versions of the compiler. For examples, implementation of std::string-s or of standard C++ containers did vary (in a subtle incompatible way, at the binary level). You could statically link the C++ standard library (but this might not always be enough, or be brittle, e.g. if the user program also needs it because his code is in C++).
由于大多数C ++编译器和标准库都是Linux上的免费软件，因此您可以深入他们的源代码以了解所有详细信息.这应该花费您多年的努力，并且您需要对此进行预算.
Since most C++ compilers and standard libraries are free software on Linux, you could dive into their source code to understand all the details. This should take you years of efforts and you need to budget that.
因此，这比您所相信的要难.至少，文档用于构建事物的C ++编译器版本以及所涉及的C ++标准库的版本.
So it is harder than what you believe. At the very least, document the version of the C++ compiler used to build your thing, and the version of the C++ standard library involved.
Another approach (which I recommend) could be to make your thing free software or open source and publish the source code on github or elsewhere, and let your user compile your source code (with his C++ compiler and C++ standard library).
与各种C ++编译器和标准C ++库的二进制兼容性实际上难以实现，因为其弊端在于细节(如果只发布一些二进制的东西).您可能会发布使用各种编译器版本(例如g++-5，g++-6，clang++-4.0等)编译的几个二进制文件.
Binary compatibility with various C++ compilers and standard C++ libraries is actually difficult to achieve, because the evil is in the details (if you release only some binary thing). You might publish several binaries compiled with various compiler versions (e.g. with g++-5, g++-6, clang++-4.0 etc...).
我不知道保证C ++库二进制兼容性的确切方法
I don't know exact way to guarantee binary compatibility for C++ library
这样的总体目标是不现实和雄心勃勃.最多您可能会发布几个二进制文件和文档，以及分别编译了确切的C ++编译器(以及版本和编译器选项)和C ++标准库.
Such a general goal is unrealistic and over-ambitious. At most you might publish several binaries and document with what exact C++ compiler (and version, and compiler options) and C++ standard library each have been compiled.
我要实现的兼容性是编译器前向兼容性和标准库前向兼容性.
The compatibility I'd like to achieve is compiler forward compatibility and standard library forward compatibility.
这通常是不可能.过去，各种C ++编译器确实破坏了ABI兼容性(并且已记录在案).罪恶在于细节(因此，即使它似乎在大多数时间似乎都奏效了，但它通常还是很容易出错).
This is impossible in general. Various C++ compilers did break ABI compatibility in the past (and this has been documented). The evil is in the details (so even if it apparently seems to work most of the time, it could often be buggy).
我说得对吗?
Am I right?
不，你是错误的，而且野心勃勃.最多可以发布一个二进制文件(也许应该发布几个)，并准确说明它的构建方式(C ++编译器和版本，编译标志，C ++标准库和版本以及什至C标准库和版本；如果您使用某些外部C ++或C库(例如Qt，Boost，Sqlite等)，则还需要记录其版本). C ++的二进制兼容性是虚构的.
No, you are wrong and over-ambitious. At most you could release a binary (probably you should release several ones) and tell exactly how it was built (what C++ compiler and version, what compilation flags, what C++ standard library and version and even what C standard library and version; if you use some external C++ or C library - like Qt, Boost, Sqlite, etc... - you also need to document their version). Binary compatibility for C++ is a fiction.
您可能并且可能应该(特别是在Linux上)使用软件包管理系统，例如为某些特定的Linux发行版(例如给定版本的Debian)发布一些 .deb 软件包.或Ubuntu).您将在二进制包中列出确切的依赖项.
You could and probably should use (on Linux particularly) package management systems, e.g. publish some .deb package for some particular Linux distributions (e.g. a given version of Debian or Ubuntu). You'll list exact dependencies in your binary package.
请注意，维护多个二进制版本(和二进制软件包)是您应该预算的许多无聊的工作.您可能会要求经理或客户的许可以打开您的库的源代码(这通常需要较少的工作).例如，您的库可能是根据 GPLv3 许可发布的:开源程序可以自由使用它，但是专有应用程序必须从您的公司购买其他许可证.
Be aware that maintaining several binary versions (and binary packages) is a lot of boring work that you should budget. You might ask permission from your manager or client to open the source of your library (and quite often this takes less work). For instance, your library might be published under GPLv3 license: open source programs could freely use it, but proprietary applications would have to buy some other license from your company.
这篇关于简单的方法来保证C ++库和C链接的二进制兼容性?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
