ARC下带CF前缀的类型与OC类型转换

在对钥匙串操作时这个函数

OSStatus SecItemCopyMatching(CFDictionaryRef query, CFTypeRef * __nullable CF_RETURNS_RETAINED result)

经常用到,表示查询Keychain里是否有符合条件的记录。第一个参数查询条件,第二个查询到结果的引用。

在非ARC模式下的基本使用方法如下

NSData *passwordData = NULL;

if (SecItemCopyMatching((CFDictionaryRef)returnDictionary, (CFTypeRef *)&passwordData) == noErr){

//ToDo

}else{

//ToDo

}

这里需要把 &passwordData 转换为 CFTypeRef * 类型。而在ARC模式下 这样写会报错

Cast of an indirect pointer to an Objective-C pointer to ‘CFTypeRef *‘ (aka ‘const void **‘) is disallowed with ARC

要解决这个问题需要对ARC模式下CF类型与OC类型之间的转换有所了解,最常用的有两个转换关键字,(__bridge type)expression 和 (__bridge_transfer Objective-C type)expression。

(__bridge type)expression //type 为id 或者 void* , expression为带有CF前缀类型的变量或者 void* 变量。如下所示

1、id obj = [[NSObject alloc] init];

void *p = (__bridge void *)obj;

id o = (__bridge id)p;

2、CGImageRef cgimage

self.layer.contents = (__bridge id)cgimage;

(__bridge_transfer Objective-C type)expression //type为OC类型 expression 可以是带有CF前缀的类型变量 。

解决上面遇到的类型转换错误可以这样做

CFTypeRef passwordDataRef;

SecItemCopyMatching((CFDictionaryRef)returnDictionary,  &passwordDataRef)

.........

NSData *passwordData = (__bridge_transfer NSData*)passwordDataRef;

这样转换之后再对passwordData 进行处理就不会报错了。

时间: 2024-10-14 05:05:41

ARC下带CF前缀的类型与OC类型转换的相关文章

ARC下OC对象和CF对象之间的桥接(bridge)

在开发iOS应用程序时我们有时会用到Core Foundation对象简称CF,例如Core Graphics.Core Text,并且我们可能需要将CF对象和OC对象进行互相转化,我们知道,ARC环境下编译器不会自动管理CF对象的内存,所以当我们创建了一个CF对象以后就需要我们使用CFRelease将其手动释放,那么CF和OC相互转化的时候该如何管理内存呢?答案就是我们在需要时可以使用__bridge,__bridge_transfer,__bridge_retained,具体介绍和用法如下

理解 ARC 下的循环引用

本文由 伯乐在线 - nathanw 翻译,dopcn 校稿.未经许可,禁止转载!英文出处:digitalleaves.com.欢迎加入翻译组. ARC 下的循环引用类似于日本的 B 级恐怖片.当你刚成为苹果开发者,你或许不会关心他们的存在.直到某天你的一个 app 因内存泄露而闪退,你才突然意识到他们的存在,并且发现循环引用像幽灵一样存在于代码的各个角落.年复一年,你开始学会如何处理循环引用,检测和避免它们,但是这部片子的恐怖结局还是在那里,随时可能出现. ARC 令许多开发者(包括我)感到失

[转]iOS中ARC下Block的循环引用

[ARC的特性] ARC下,所有NSObject类型指针, 1. 默认为__strong类型 2. 可以显示的指定为__weak类型,__weak类型指针在所指向对象销毁后会自动置为nil 3. __autorelesing类型用于inout参数类型 ARC下,当一个函数返回一个NSObject指针时,编译器会帮我们实现autorelease调用.例如: return pObject; 编译器会帮我们扩展为 return [pObject autorelease]; ARC下,不能显式relea

Objective-C中,ARC下的 strong和weak指针原理解释

Objective-C中,ARC下的 strong和weak指针原理解释 提示:本文中所说的"实例变量"即是"成员变量","局部变量"即是"本地变量" 一.简介 ARC是自iOS 5之后增加的新特性,完全消除了手动管理内存的烦琐,编译器会自动在适当的地方插入适当的retain.release.autorelease语句.你不再需要担心内存管理,因为编译器为你处理了一切 注意:ARC 是编译器特性,而不是 iOS 运行时特性(除

八.OC基础加强--1.autorelease的用法 2.ARC下内存管理 3.分类(category)4.block的学习

1.autorelease的用法   1.自动释放池及autorelease介绍 (1)在iOS程序运行过程中,会创建无数个池子,这些池子都是以栈结构(先进后出)存在的. (2)当一个对象调用autorelease时,会将这个对象放到位于栈顶的释放池中 . 2.为什么会有autorelease? OC的内存管理机制中比较重要的一条规律是:谁申请,谁释放. 但有些情况下,开发者并不能确定某些对象何时释放.这时候就需要自动释放池. 它的好处是: (1)不需要再关心对象释放的时间 : (2)不需要再关

__block在arc和非arc下含义一样吗?

Block属性的声明,首先需要用copy修饰符,因为只有copy后的Block才会在堆中,栈中的Block的生命周期是和栈绑定的,可以参考之前的文章(iOS: 非ARC下返回Block). 比如这样一个Block类型: typedef void (^MyBlockType)(int); @property (copy) MyBlockType myBlock; if (self.myBlock) { //此时,走到这里,self.myBlock可能被另一个线程改为空,造成crash //注意:a

iOS: ARC和非ARC下使用Block属性的问题

1. Block的声明和线程安全 Block属性的声明,首先需要用copy修饰符,因为只有copy后的Block才会在堆中,栈中的Block的生命周期是和栈绑定的,可以参考之前的文章(iOS: 非ARC下返回Block). 另一个需要注意的问题是关于线程安全,在声明Block属性时需要确认“在调用Block时另一个线程有没有可能去修改Block?”这个问题,如果确定不会有这种情况发生的话,那么Block属性声明可以用nonatomic.如果不肯定的话(通常情况是这样的),那么你首先需要声明Blo

ARC下block使用情况

ARC与MRC的block有着一些区别,笔记整理ARC的block,仅仅是自己参考的笔记,详情请参考 http://www.cnbluebox.com/?p=255 在开始之前,请新建一个Model类,写几个如下的属性,用于后面测试block的特性. Block的类型与内存管理 根据Block在内存中的位置分为三种类型NSGlobalBlock,NSStackBlock, NSMallocBlock. NSGlobalBlock:类似函数,位于text段: NSStackBlock:位于栈内存,

iOS ARC下dealloc过程及.cxx_destruct的探究

前言 这次探索源自于自己一直以来对ARC的一个疑问,在MRC时代,经常写下面的代码: 1 2 3 4 5 6 7 8 9 - (void)dealloc {     self.array = nil;     self.string = nil;     // ... //     // 非Objc对象内存的释放,如CFRelease(...)     // ... //     [super dealloc]; } 对象析构时将内部其他对象release掉,申请的非Objc对象的内存当然也一并