关于toll-free bridging在casting时的几种模式

关于什么是toll-free bridging在这里我就不进行解释了,这里只说一下几种casting的模式。

在进行toll-free bridging转换的时候,只有下面这3种模式:

  1. __bridge
  2. __bridge_retained(也可以使用CFBridgingRetain())
  3. __bridge_transfer(也可以使用CFBridgingRelease())

对于这几种模式的解释,文档里也是有的,但可能是我才疏学浅,看了几遍也没搞明白到底是什么意思,所以最后只有通过试验来了解在使用这几种关键字进行casting的时候,究竟会发生什么。

为了搞明白这些关键字的用途,我必须先搞明白为什么在casting的时候要用他们。首先,所有Core Foundation所建立的对象都必须手动管理其reference count(当然,也可以在建立之后通过casting转交给Cocoa Foundation pointer,来让ARC管理),其次ARC虽然是会自动管理object的释放,但它的内部原理依然是用的reference counting,那么由于在执行casting的时候,ARC并不知道是否应该为pointer所指的object增加或是减少reference count(或者既不增加也不减少),因此我们必须在代码中给出明确指示,而这个指示一共有3种,就是上面说的那3个关键字。下面就是这3个关键字所产生的作用的具体描述:

____bridge__. 当将 Cocoa Foundation pointer转换成Core Foundation pointer的时候,使用__bridge不会增加或减少pointer所指的对象的reference count. 而假如是将Core Foundation pointer转换成Cocoa Foundation pointer的时候使用__bridge的话,则会将pointer所指对象的reference count加1。

____bridge_retained__(也可以使用CFBridgingRetain()).只能在将Cocoa Foundation pointer 转换为Core Foundation的pointer时使用. 转换后,会将pointer所指object的reference count加1.

____bridge_transfer__(也可以使用CFBridgingRelease()). 只能在将Core Foundation的pointer转换为Cocoa Foundation的pointer时使用. 转换后,不会增加或减少pointer所指object的reference count.

事实上,使用这3种方法进行casting各有个的优点,这其实完全取决于你的爱好与编程风格

__假如你希望完全分开管理Core Foundation所创建的object 与 Cocoa Foundation在ARC环境下所创建的object的释放问提的话,那么你就应该用____bridge. 因为在将Cocoa Foundation pointer转换成Core Foundation pointer的时候,object的reference count并不会变化,这样当Core Foundation使用完这个object的时候,并不需要担心release这个object的问题,这个object的reference count依然在ARC的控制之下。而当在将Core Foundation pointer转换成Cocoa Foundation pointer的时候,所指Object的reference count会增加1,但是由于是在ARC环境下,所以当Cocoa Foundation pointer使用完这个Object后,会自动将这个object 的reference count减去1,这样一增一减,则又持平了,所以也不会影响到Core Foundation部分的代码对这个object的管理。

__假如你希望将Core Foundation所建立的对象交给ARC进行管理,则在将Core Foundation pointer转换成Cocoa Foundation pointer的时候,就应该使用____bridge_transfer。比如下面这个例子:

CFUUIDRef newUniqueID = CFUUIDCreate(kCFAllocatorDefault);
// casting的时候加上__bridge_transfer,所指对象的reference count不会变
uuid = (__bridge_transfer NSUUID*)newUniqueID;
// 由于uuid是属于ARC管理,在将pointer设为nil后,其所指对象的reference count会自动减1
// 也就是会变为0,这样就释放了。
uuid = nil;

__最后,假如你希望将 Cocoa Foundation所建立的对象交给Core Foundation进行手动reference count管理,则在将Cocoa Foundation pointer转换成Core Foundation pointer的时候,则可使用__bridge_retained。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,293评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,604评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,958评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,729评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,719评论 5 366
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,630评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,000评论 3 397
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,665评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,909评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,646评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,726评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,400评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,986评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,959评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,197评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,996评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,481评论 2 342

推荐阅读更多精彩内容