这就是维基百科所说的:
在计算机软件中,应用程序二进制接口(ABI)描述应用程序(或任何类型)程序与操作系统或另一应用程序之间的低级接口.
ABI涵盖了数据类型,大小和对齐等细节; 调用约定,它控制函数参数的传递方式并返回检索的值; 系统调用号码以及应用程序应如何向操作系统进行系统调用; 并且在完整的操作系统ABI的情况下,目标文件,程序库等的二进制格式.完整的ABI(例如英特尔二进制兼容性标准(iBCS))允许来自支持该ABI的一个操作系统的程序在不修改任何其他此类系统的情况下运行,前提是存在必要的共享库,并且满足类似的先决条件.
我猜ABI是一种约定或标准,编译器/链接器使用此约定来生成目标代码.是对的吗？如果是这样,谁制定了这些约定(公司或某个组织)？什么时候没有ABI？我们可以参考哪些关于这些ABI的文件？
例如,我有两个名为file1.swift和file2.swift的文件.
file1.swift
import UIKit
class A: B {
}
file2.swift
import UIKit
class C: A{
}
我正在读取公共类不能在模块之外进行子类化.这里我有子类C.我试图理解模块在这里意味着什么.我为这两个文件导入了相同的模块UIKit.那么这两个文件是同一个模块吗？这样我就可以继承了.或者两个文件都有不同的模块,即使我导入相同的UIKit？
任何人都可以解释什么是模块？
资源:
具有公共访问权限或任何更严格的访问级别的类只能在定义它们的模块中进行子类化.
具有公共访问权限或任何更具限制性的访问级别的类成员只能在定义它们的模块中被子类覆盖.
我和Carthage以及Cocoapods都有过一个项目.它们都有一个共同的依赖(PureLayout,确切地说).奇怪,但项目编译好,没有任何关于类重新声明等的错误.所以问题是:当我调用PureLayout的方法 - 迦太基或Cocoapods的方法时,它为什么工作以及实际使用了哪个版本的依赖？
在函数中使用struct参数时,clang将更改函数签名.签名将是一个相同大小的强制int,而不是使用结构类型.在我的编译器项目中,我使用llvm结构类型作为方法签名(这似乎更合乎逻辑).
这不会是一个问题,除了LLVM在使用struct或coerced类型时产生的汇编是不同的而不是调用兼容的事实.这导致我的编译器不与具有结构的C函数ABI兼容.
为什么clang这样做？这是C ABI中指定的内容吗？
这是一个简单的示例C源文件:
struct TwoInt { int a, b; };
struct EightChar { char a, b, c, d, e, f, g, h; };
void doTwoInt(struct TwoInt a) {}
void doEightChar(struct EightChar a) {}
int main()
{
struct TwoInt ti;
struct EightChar fc;
doTwoInt(ti);
doEightChar(fc);
return 0;
}
从Clang得到的LLVM-IR
%struct.TwoInt = type { i32, i32 }
%struct.EightChar = type { i8, i8, i8, i8, i8, i8, i8, i8 }
define void @doTwoInt(i64 %a.coerce) nounwind uwtable {
%a …第三方公司为我提供了一个框架。我想检查嵌入在框架中的 swift 版本（2.2、2.3 或 3.x）框架目录包含 libswift dylib 文件。
如何检查框架中使用的 swift 版本？
谢谢 ！
我创建了一个名为 的框架Communication，框架容器内有一个module.modulemap文件。
模块.modulemap
framework module Communication {
umbrella header "Communication.h"
export *
module * { export * }
}
我可以理解该模块需要伞头将其暴露给包含应用程序/目标。
但是其他两行代码的含义是什么。
export *
module * { export * }
如果有人知道这条线出口的是什么？
我想知道为什么 int 的大小取决于 C 和 C++ 中使用的操作系统。如果指针的大小不同是可以的，但是为什么整数的大小不同呢？如果 16 位操作系统 sizeof(int) = 2 字节，则对于 32 位操作系统 sizeof(int) = 4 字节。为什么这样？
谢谢。
我遇到过一种情况,我可能想要使用一个版本的gcc编译的C++共享对象库,其中一些代码将使用另一个版本的gcc编译.特别是,我想使用返回一些STL容器的方法,如std::string和std::map.
在GCC网站和许多老计算器职位(如这里)讨论这个问题.我目前的理解是
此问题的大多数问题和大多数帖子都是关于.so文件和.dll文件之间的交叉兼容性.由于编译器ABI不同,这非常困难.
对于使用不同版本的gcc(至少使用gcc版本> = 3.4)编译的.so文件之间的交叉兼容性,您需要确保的是标准库API没有更改(如果有,则有双重ABI支持).
我的问题与它在机器级别的工作方式有关.看起来有可能gcc可以更改标头实现std::string,即使库API没有改变,以使其更有效或出于其他原因.如果是这样,则使用两个不同的std::string头编译两个不同的代码片段,并且基本上定义具有相同名称的两个不同的类.我们如何能够保证,当我们将std::string使用一个头的代码传递给使用另一个头的代码时,该对象不会以某种方式被破坏或误读？
例如,假设我有以下文件:
// File a.h:
#ifndef FILE_A
#define FILE_A
#include <string>
class X {
public:
std::string f();
};
#endif // FILE_A
// File a.cpp:
#include "a.h"
std::string X::f() {
return "hello world";
}
// File b.cpp:
#include <iostream>
#include <string>
#include "a.h"
int main() {
std::string x = X().f();
std::cout << x << std::endl;
}
(这个类的唯一目的X是在我测试它是如何工作的时候在共享对象库中引入更多名称修改.) …