Question

当我在objective-c中对类的ivars进行冲突定义时（不是在同一个文件中重新声明类，而是使用diff ivars命名相同的类，编译器不会发出警告或更好的错误）。但是，这两组ivars都可以通过相应文件中的相应方法使用。例如

Foo.m：

@interface foo {
int a;
}
- (int)method;
@end

@implementation foo

- (int)method {
    return a;
}

@end

Bar.m：

@interface foo {
float baz;
}

@end

@implementation foo (category)
- (float)blah {
    return baz;
}
@end

编译时没有警告或错误。这是故意的吗？这是一个未经检查的错误吗？（对于记录，a和baz实际上是相同的内存位置。）

编辑：对于记录我说的是iPhone OS，我相信它使用与64位MacOS相同的运行时

Answer 1

虽然明显坏了，但代码应该在没有任何警告的情况下编译，因为编译器没有足够的信息来知道如何警告。如果编译正确，它只会在64位（这是新的Objective-C ABI的后果，而不是直接来自非脆弱的ivars）中生成完全不同的链接器错误。

如果将int main() {}添加到foo.m然后使用命令行gcc -arch x86_64 foo.m -lobjc进行编译，则链接错误会消失，因为objc运行时库提供了完成链接所需的空vtable符号。

在编译期间，将每个.m文件视为一个独立的编译单元。当编译器编译.m文件时，它只知道该.m文件中的内容，该.m文件中导入的内容提供的内容，以及 - 如果为其配置了项目 - 在该项目的预编译标题。

因此，当你在bar.m中说：

@interface foo {
float baz;
}

@end

@implementation foo (category)
- (float)blah {
    return baz;
}
@end
int main() {}

编译器在foo.m中没有声明的概念。生成的代码描述了访问ivar baz的类foo上的类别。如果该类在链接时不存在，则会在现在抛出错误，给定你的foo.m和bar.m并添加上面的main函数，让我们尝试一些不同的编译：

gcc -arch i386 foo.m -lobjc
Undefined symbols:
  "_main", referenced from:
      start in crt1.10.6.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

有道理，因为我们没有在foo.m中定义main（）函数。 64位编译也是如此。

gcc -arch i386 bar.m -lobjc

在没有警告的情况下编译和链接。要了解原因，请查看生成的符号（删除了大约十几个不相关的符号）：

nm -a a.out
00001f52 t -[foo(category) blah]
00000000 A .objc_category_name_foo_category

因此，二进制文件在类category上包含名为foo的类别。没有链接错误，因为链接器实际上并未尝试解析类别。它假定在运行时解析类别之前，类foo会神奇地出现。

您可以使用ivar跟随运行时的类/类别解析：

env OBJC_PRINT_CLASS_SETUP=YES ./a.out 
objc[498]: CONNECT: pending category 'foo (category)'
objc[498]: CONNECT: class 'Object' now connected (root class)
objc[498]: CONNECT: class 'Protocol' now connected
objc[498]: CONNECT: class 'List' now connected

因此，该类别被标记为待定。一旦foo出现，运行时就会将其连接起来！

现在，64位......

gcc -arch x86_64 bar.m -lobjc
Undefined symbols:
  "_OBJC_IVAR_$_foo.baz", referenced from:
      -[foo(category) blah] in ccvX4uIk.o
  "_OBJC_CLASS_$_foo", referenced from:
      l_OBJC_$_CATEGORY_foo_$_category in ccvX4uIk.o
      objc-class-ref-to-foo in ccvX4uIk.o
ld: symbol(s) not found

链接错误是因为现代Objective-C ABI实际上由于各种原因导致为实例变量和类别发出正确的符号，包括添加可以帮助验证程序的元数据（就像在这种情况下那样）。 / p>

没有编译错误（这是正确的行为）和链接错误是有意义的。现在，如何将两者联系在一起？

在32位的情况下，一切都编译和链接没有错误。因此，我们需要查看符号并在ObjC调试中查看发生了什么：

gcc -arch i386 bar.m foo.m -lobjc
nm -a a.out
00001e0f t -[foo method]
00001dea t -[foo(category) blah]
00000000 A .objc_category_name_foo_category
00003070 S .objc_class_name_foo
env OBJC_PRINT_CLASS_SETUP=YES ./a.out 
objc[530]: CONNECT: attaching category 'foo (category)'
objc[530]: CONNECT: class 'Object' now connected (root class)
objc[530]: CONNECT: class 'Protocol' now connected
objc[530]: CONNECT: class 'List' now connected
objc[530]: CONNECT: class 'foo' now connected (root class)

啊哈！现在有一个类foo，运行时在启动时将类别连接到类。显然，返回baz ivar的方法将会失败。

但是64位链接器失败了：

gcc -arch x86_64 bar.m foo.m -lobjc
Undefined symbols:
  "_OBJC_IVAR_$_foo.baz", referenced from:
      -[foo(category) blah] in ccBHNqzm.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

通过添加实例变量的符号，链接器现在可以捕获错误地重新声明类的情况（如bar.m的@interface中所做的那样）。

Answer 2

我认为你所做的是extended课程。

GCC编译器 - 错误或未指定的行为？

2 个答案: