深入理解 OC/C++ 闭包

2023-02-19 0 479

大背景

苹果公司的 Objective-C C++容许使用者在同一源文档里民主自由地混和采用 C++和 Objective-C,T2390后的词汇叫 Objective-C++。相对于其他词汇(比如 Swift、Kotlin、Dart 等)和 C++的文档隔绝和造桥通讯(比如 Kotlin 采用JNI,Dart 采用FFI),Objective-C 和 C++的同文档T2390形式毫无疑问是更让人杨开第的。OC/C++T2390尽管可以在两个文档中展开撰写,但有许多小常识须要介绍:Objective-C++没为 OC 类减少 C++的机能,也没为 C++减少 OC 的机能,比如:无法用 OC 句法初始化 C++第一类,也无法为 OC 第一类减少缺省和析构表达式,也无法将thisself相互代替采用。类的数据库系统是分立的,C++类无法承继 OC 类,OC 类也无法承继 C++类。

责任编辑主要就就以后自相矛盾的 OC 的Block和 C++的lambdaT2390难题做许多积极探索。

试验自然环境:C++版为 C++14,OC 只限于 ARC。

基本上介绍

在深入细致积极探索以后,先透过对照的形式介绍下两者:

句法

^(intx, NSString *y){}// ObjC, take int and NSString* [](int x, std::string y){} // C++, take int and std::string ^{ return 42; }// ObjC, returns int []{ return 42; } // C++, returns int ^int { if(something) return 42; else return 43; } []()->int { if(something) return 42; else return 43; }

原理

OC 的Block的底层能参考《深入细致研究 Block 捕获外部变量和 __block 实现原理》(https://halfrost.com/ios_block/),这里不做深入细致探究,仅仅是要展开代码达到对照效果。

– (void)viewDidLoad { [superviewDidLoad];int x = 3; void(^block)(int) = ^(int a) { NSLog(@”%d”, x); }; block(5); }

透过clang -rewrite-objc重写,能得到以下结果:

struct __ViewController__viewDidLoad_block_impl_0 { struct __block_impl impl; struct__ViewController__viewDidLoad_block_desc_0* Desc;int x; __ViewController__viewDidLoad_block_impl_0(void *fp, struct __ViewController__viewDidLoad_block_desc_0 *desc, int _x, int flags=0) : x(_x) { impl.isa = &_NSConcreteStackBlock; impl.Flags = flags; impl.FuncPtr = fp; Desc = desc; } };static void __ViewController__viewDidLoad_block_func_0(struct__ViewController__viewDidLoad_block_impl_0 *__cself,int a) { int x = __cself->x; // bound by copy NSLog((NSString*)&__NSConstantStringImpl__var_folders_st_jhg68rvj7sj064ft0rznckfh0000gn_T_ViewController_d02516_mii_0, x); }static struct__ViewController__viewDidLoad_block_desc_0 { size_t reserved; size_t Block_size; } __ViewController__viewDidLoad_block_desc_0_DATA = {0, sizeof(struct__ViewController__viewDidLoad_block_impl_0)};static void _I_ViewController_viewDidLoad(ViewController * self, SEL _cmd) { ((void(*)(__rw_objc_super *, SEL))(void *)objc_msgSendSuper)((__rw_objc_super){(id)self, (id)class_getSuperclass(objc_getClass(“ViewController”))}, sel_registerName(“viewDidLoad”)); int x = 3; void(*block)(int) = ((void (*)(int))&__ViewController__viewDidLoad_block_impl_0((void*)__ViewController__viewDidLoad_block_func_0, &__ViewController__viewDidLoad_block_desc_0_DATA, x)); ((void (*)(__block_impl *, int))((__block_impl *)block)->FuncPtr)((__block_impl *)block,5); }

而 C++ lambda采取了截然不同的的实现机制,会把lambda表达式转换为两个匿名 C++类。这里借助cppinsights 看下 C++ lambda的实现。

#include <cstdio> struct A { int x; int y; }; int main() { A a = {1, 2}; int m = 3; auto add = [&a, m](int n)->int { return m + n + a.x + a.y; }; m = 30; add(20); } #include <cstdio> struct A { int x; int y; }; int main() { A a = {1, 2}; int m = 3; class __lambda_12_15 { public:inline int operator()(int n) const { return ((m + n) + a.x) + a.y; } private: A & a; int m; public: __lambda_12_15(A & _a,int& _m) : a{_a} , m{_m} {} }; __lambda_12_15 add = __lambda_12_15{a, m}; m =30; add.operator()(20); return 0; }

能看到:lambda表达式add被转换Sonbhadra__lambda_12_15,且重载了操作符(),对add的初始化也被转换为对add.operator()的初始化。

捕获变量

OC Block只可能透过普通形式和__block形式捕获变量:

int x = 42; void(^block)(void) = ^{ printf(“%d\n”, x); }; block(); // prints 42 __block int x = 42; void (^block)(void) = ^{ x =43; }; block(); // x is now 43

C++ lambda带来了更多的灵活性,能透过以下这些形式捕获变量:

[] Capture nothing [&] Capture any referenced variableby reference [=] Capture any referenced variable bymaking a copy [=, &foo] Capture any referenced variableby making a copy, but capture variable foo byreference [bar] Capture barby making a copy; dont copy anything else [this] Capture the this pointer of the enclosing classint x = 42; int y = 99; int z = 1001; auto lambda = [=, &z] { // cant modify x or y here, but we can read them z++; printf(“%d, %d, %d\n”, x, y, z); }; lambda(); // prints 42, 99, 1002 // z is now 1002

内存管理

OC 的Block和 C++ lambda均起源于栈第一类,然而两者的后续发展截然不同。OC 的Block本质是 OC 第一类,他们是透过引用形式存储,从来不会透过值形式存储。为了延长生命周期,OCBlock必须被拷贝到堆上。OC Block遵循 OC 的引用计数规则,copyrelease必须平衡(Block_copyBlock_release同理)。首次拷贝会把Block从栈上移动到堆上,再次拷贝会减少其引用计数。当引用计数为 0 的时候,Block会被销毁,其捕获的第一类会被release

C++ lambda按值存储,而非按引用存储。所有捕获的变量都会作为匿名类第一类的成员变量存储到匿名类第一类中。当lambda表达式被拷贝的时候,这些变量也都会被拷贝,只须要触发适当的缺省和析构表达式即可。这里面有两个极其重要的点:透过引用捕获变量。这些变量是作为引用存储在匿名第一类中的,他们并没得到任何特殊待遇。这意味着这些变量的生命周期结束之后,lambda仍然有可能会去访问这些变量,从而造成未定义的行为或者崩溃,比如:

– (void)viewDidLoad { [super viewDidLoad]; int x = 3; lambda = [&x]() -> void { NSLog(@”x = %d”, x); }; } – (void)touchesBegan:(NSSet<UITouch *> *)touches withEvent:(UIEvent *)event { lambda(); } // 从输出结果中能看到x是两个随机值 2022-02-12 23:15:01.375925+0800 BlockTest[63517:1006998] x = 32767

相对来说,this指向的存储在堆上,它的生命周期有一定的保证,但即使如此,也无法绝对保证生命周期安全,有些情况下须要借助智能指针延长生命周期。

auto strongThis = shared_from_this(); doSomethingAsynchronously([strongThis, this]() { someMember_ = 42; });

旋量群混和捕获难题

前面讨论的内容都是相互分立的,OC 的Block并未涉及 C++第一类,C++的lambda也没牵扯 OC 第一类,这大概是我们最希望看到的,但T2390过程中会发现这只是自己的一厢情愿。两者往往会相互把自己的魔杖伸向对方领域,从而会引发许多比较费解的难题。

C++的lambda捕获OC第一类

C++的lambda能捕获 OC 变量吗?如果能的话,会有循环引用的难题吗?如果有循环引用的难题,该怎么处理呢?

值捕获 OC 第一类

如代码所示,在OCClass类中有两个 C++字段cppObj,在OCClass的初始化方法中,对cppObj展开了初始化,并对其字段callback展开了赋值。能看到,在lambda中对self展开了捕获,按照前面的规则,能认为值捕获。

class CppClass { public: CppClass() { } ~CppClass() { } public: std::function<void()> callback; }; @implementation OCClass { std::shared_ptr<CppClass> cppObj; } – (void)dealloc { NSLog(@”%s”, __FUNCTION__); } – (instancetype)init { if (self = [superinit]) { cppObj = std::make_shared<CppClass>(); cppObj->callback = [self]() -> void { [self executeTask]; }; } return self; } – (void)executeTask { NSLog(@”execute task”); } OCClass *ocObj = [[OCClass alloc]init];

不幸的是,这样的捕获形式会发生循环引用:OCClass第一类ocObj持有cppObjcppObj透过callback持有了ocObj

深入理解 OC/C++ 闭包

看下对应的汇编代码,能发现捕获的时候,触发了ARC语义,自动对self展开了retain

深入理解 OC/C++ 闭包

这几行汇编代码对self减少引用计数。

0x10cab31ea <+170>: movq –0x8(%rbp), %rdi 0x10cab31ee <+174>: movq0x5e7b(%rip), %rax ; (void *)0x00007fff2018fa80: objc_retain 0x10cab31f5 <+181>: callq *%rax

最后来看一下匿名类的参数,能发现selfOCClass *类型,是两个指针类型。

深入理解 OC/C++ 闭包

那么能简单地认为捕获伪代码如下,在ARC语义下会发生retain行为:

__strong __typeof(self) capture_self =self; // 展开 __strong OCClass * capture_self = self;

为介绍决循环引用的难题,能采用__weak

cppObj = std::make_shared<CppClass>(); __weak __typeof(self) wself = self; cppObj->callback = [wself]() -> void { [wself executeTask]; };
深入理解 OC/C++ 闭包

再次观察汇编代码,发现前面的objc_retain逻辑已经消失,代替的逻辑为objc_copyWeak

引用捕获 OC 第一类

那么是否能透过引用捕获来捕获self呢?

cppObj = std::make_shared<CppClass>(); cppObj->callback = [&self]() -> void { [self executeTask]; };

能看到汇编代码中同样没objc_retain逻辑。

深入理解 OC/C++ 闭包

最后来看一下匿名类的参数,能发现selfOCClass *&类型,是两个指针引用类型。

深入理解 OC/C++ 闭包

能看到引用捕获并不会对self展开retain,可以简单的认为捕获伪代码如下,在ARC语义下不会发生retain行为。

__unsafe_unretained __typeof(self)& capture_self = self; // 展开 __unsafe_unretained OCClass *&capture_self = self;

被捕获的 OC 第一类什么时候释放?

以这个代码片段为例:

auto cppObj = std::make_shared<CppClass>(); OCClass2 *oc2 = [[OCClass2 alloc] init]; cppObj->callback = [oc2]() -> void { [oc2 class]; };
深入理解 OC/C++ 闭包

能看到,在CppClass的析构表达式中对std::function展开了析构,而std::function则对其捕获的 OC 变量 oc2 展开了释放。

结论

C++ lambda的本质是创建两个匿名结构体类型,用来存储捕获的变量。ARC会保证包含 OC 第一类字段的 C++结构体类型遵循ARC语义:

C++结构体的缺省会将 OC 第一类字段初始化为nil当该 OC 第一类字段被赋值的时候,会release掉以后的值,并retain新值(如果是block,会展开copy);当 C++结构体的析构表达式被初始化的时候,会release掉 OC 第一类字段。

C++ lambda会透过值或者引用的形式捕获 OC 第一类。

引用捕获 OC 第一类相当于采用__unsafe_unretained,存在生命周期难题,本身比较危险,不太推荐;而值捕获的形式相当于采用__strong,可能会引起循环引用,必要的时候能采用__weak

OC 的 Block 如何捕获 C++第一类?

反过来看看 OC 的Block是怎么捕获 C++第一类的。

代码中的HMRequestMonitor是两个 C++结构体,其中的WaitForDoneSignalDone方法主要就是为了实现同步。

struct HMRequestMonitor { public: bool WaitForDone() { returnis_done_.get(); }void SignalDone(bool success) { done_with_success_.set_value(success); } ResponseStruct& GetResponse() { return response_; } private: ….. };

upload方法采用HMRequestMonitor第一类,达到同步等待网络请求结果的目的(为了排版,代码有所调整)。

hermas::ResponseStruct HMUploader::upload( const char* url, const char* request_data, int64_t len,const char* header_content_type, const char* header_content_encoding) { HMRequestModel *model = [[HMRequestModel alloc] init]; …… auto monitor = std::make_shared<hermas::HMRequestMonitor>(); std::weak_ptr<hermas::HMRequestMonitor> weakMonitor(monitor); DataResponseBlock block = ^(NSError *error, id data, NSURLResponse *response) { weakMonitor.lock()->SignalDone(true); }; [m_session_manager requestWithModel:model callBackWithResponse:block]; monitor->WaitForDone();return monitor->GetResponse(); }

这里直接采用std::weak_ptr

不采用__block

深入理解 OC/C++ 闭包
深入理解 OC/C++ 闭包

透过试验能得到以下结论:

C++的第一类会被 OC 的Block捕获,且透过值传递形式。透过断点能发现初始化的是std::weak_ptr的拷贝缺省。template<class _Tp> inline weak_ptr<_Tp>::weak_ptr(weak_ptrconst& __r) _NOEXCEPT : __ptr_(__r.__ptr_), __cntrl_(__r.__cntrl_) { if(__cntrl_) __cntrl_->__add_weak(); }monitor的弱引用计数变化如下:初始化monitor时, weak_count = 1;初始化weakMonitor时,weak_count = 2,减少 1;OC Block 捕获后,weak_count = 4,减少了 2。透过观察汇编代码,有 2 处:首次捕获的时候,对weakMinotor展开了复制,在汇编代码 142 行;Block从栈上拷贝到堆上的时候,再次对weakMinotor展开了复制,在汇编 144 行;

这里须要注意的是:C++的weak_count比较奇怪,它的值 = 弱引用个数 + 1,这么设计的原因比较复杂,具体能参考:https://stackoverflow.com/questions/5671241/how-does-weak-ptr-work

如果此处不采用std::weak_ptr,而是直接捕获std::shared_ptr,被捕获后其强引用计数为 3,逻辑和上述的std::weak_ptr是一致的。(就本质上来说,std::shared_ptrstd::weak_ptr都是 C++类)

std::shared_ptr<hermas::HMRequestMonitor> monitor = std::make_shared<hermas::HMRequestMonitor>(); DataResponseBlock block = ^(NSError * _Nonnull error, id _Nonnull data, NSURLResponse * _Nonnull response) { monitor->SignalDone(true); }; (lldb) po monitor std::__1::shared_ptr<hermas::HMRequestMonitor>::element_type @ 0x00006000010dda58 strong=3 weak=1

采用__block

那么是否能采用__block修改被捕获的 C++变量呢?透过试验发现是可行的。

深入理解 OC/C++ 闭包
深入理解 OC/C++ 闭包

能得到以下结论:

OC 的Block能透过引用传递形式捕获 C++第一类;monitorweak引用计数如下:初始化monitor时, weak_count = 1;初始化weakMonitor时,weak_count = 2,减少 1;OC Block捕获后,weak_count = 2,主要就是由于移动缺省被触发,只是所有权的转移,不会改变引用计数;
深入理解 OC/C++ 闭包

__block 的疑问

介绍 C++的同学可能会疑惑,这里既然是移动缺省被触发,只是所有权发生了转移,意味着monitor作为右值被传递进来,已经变为nullptr被消亡,那么为什么示例中的monitor还能继续访问?能来验证一下:

当首次执行完如下代码的时候
深入理解 OC/C++ 闭包

会发现monitor变量的地址为:

(lldb) po &monitor 0x0000700001d959e8 当执行block赋值的时候,会初始化到std::shared_ptr的移动缺省中:
深入理解 OC/C++ 闭包
深入理解 OC/C++ 闭包
移动缺省中的this地址为0x0000600003b0c830;__r的地址也是0x0000700001d959e8,和monitor的地址一致。当执行完block的时候,再次打印monitor的地址,会发现monitor的地址已经发生了变化,和第二步中的this保持了一致,这说明monitor已经变为第二步中的this(lldb) po &monitor 0x0000600003b0c830

整个过程中,monitor前后地址发生了变化,分别是 2 个不同的std::shared_ptr第一类。所以monitor还能继续被访问。

被捕获的 C++第一类何时释放?

深入理解 OC/C++ 闭包

同样在 OC 的Block释放的时候,会对其捕获的 C++第一类展开释放。

捕获 shared_from_this

C++的this是两个指针,本质就是两个整数,OC 的Block捕获this和捕获一个整数并没本质上的区别,所以这里不再详细讨论。这里重点看下 C++的shared_from_this类,它是 this 的智能指针版。

两个 C++类如果想访问shared_from_this,必须承继自类enable_shared_from_this,并把自己的类名作为模板参数传入。

class CppClass : public std::enable_shared_from_this<CppClass> {public: CppClass(){} ~CppClass() {} void attachOCBlock(); public: OCClass2 *ocObj2; void dosomething() {} }; void CppClass::attachOCBlock() { ocObj2 = [[OCClass2 alloc] init]; autoshared_this = shared_from_this(); ocObj2.ocBlock = ^{ shared_this->dosomething(); }; }@interface OCClass2 : NSObject @property void (^ocBlock)(); @end auto cppObj = std::make_shared<CppClass>(); cppObj->attachOCBlock();

根据前面的结论,在CppClass成员表达式attachOCBlock中,ocBlock直接捕获shared_from_this同样会引发循环引用,同样采取std::weak_ptr来解决。

void CppClass::attachOCBlock() { ocObj2 = [[OCClass2 alloc] init]; std::weak_ptr<CppClass> weak_this = shared_from_this(); ocObj2.ocBlock = ^{ weak_this.lock()->dosomething(); }; }

结论

OC 的Block能捕获 C++第一类。

如果采用普通形式捕获栈上的 C++第一类,会初始化拷贝缺省;如果采用__block形式捕获栈上的 C++第一类,会初始化移动缺省,并且__block修饰的 C++第一类在被捕获的时候,会展开重定向。

总结

责任编辑一开始分别从句法、原理、变量捕获和内存管理 4 个维度,对 OC 的Block和 C++的lambda展开了简单的对比,然后花了较多的篇幅重点讨论OC/C++的旋量群混和捕获难题。之所以如此大费周章,是因为不想稀里糊涂地「猜想」和「试错」,只有深入细致介绍背后机制,才能写出较好的 OC/C++T2390代码,同时也希望能给有同样困惑的读者带来许多帮助。然而对于OC/C++整个T2390领域来说,这仅仅是冰山一角,疑难难题仍然重重,期待未来能带来更多的积极探索。

参考文档

https://isocpp.org/wiki/faq/objective-chttp://www.philjordan.eu/article/mixing-objective-c-c++-and-objective-c++https://releases.llvm.org/12.0.0/tools/clang/docs/AutomaticReferenceCounting.htmlhttps://releases.llvm.org/12.0.0/tools/clang/docs/BlockLanguageSpec.html#c-extensionshttps://mikeash.com/pyblog/friday-qa-2011-06-03-objective-c-blocks-vs-c0x-lambdas-fight.html

相关文章

发表评论
暂无评论
官方客服团队

为您解决烦忧 - 24小时在线 专业服务