假设我从某个函数中获取了一个C字符串:
char * mystring = SomeCFunction(...);
我拥有这个字符串(当我完成时,我负责释放它).
如果,在Objective-C中,我创建了一个NSString *using:
NSString * mynsstring = [NSString stringWithCString:mystring
encoding:NSUTF8StringEncoding];
我还有责任释放原来的C字符串吗？
我假设答案是肯定的,但是我在文档中找不到明确的答案 - 而相反方法的功能(cStringUsingEncoding)虽然很明显,却让我暂停,因为它为你处理cString释放.
如果答案是肯定的,那么我还要负责确保在使用之前我没有释放c字符串NSString *,或者函数是否为我复制字符串？我问这个是因为文档stringWithCString说它:
返回一个字符串,其中包含给定C数组中的字节,并根据给定的编码进行解释.
这仍然让我想知道它是否真的复制了字节,或者只是在内部指向它们(我基本上只是在做一个演员).
我正在使用CFSTR函数从常量c字符串创建CFString,我在我的守护进程中经常调用此函数.
来自文档:
CFSTR返回的值具有以下语义:
我应该使用保留和释放吗？
我应该在哪里下载核心基础库？我有一个包含CoreFoundation/CoreFoundation.h的程序......它是一个iPhone应用程序,但我认为核心基础代码将在linux上运行.
我希望通过这项研究了解CoreFoundation CGColor对象的内部结构.我可以从免费的石英项目中找到CGColor结构的样本定义,它似乎与IOS声明相符(依赖于我的研究).
typedef struct CGColor {
CFRuntimeBase obj;
CFTypeID colorID;
CGColorSpaceRef colorSpace;
CGPatternRef pattern;
size_t numberOfComponents;
CGFloat *components;
} *CGColorRef;
(colorID字段由free quartz命名为nextID,但我认为它是IOS的唯一标识,因此它不是一种下一个标识符.)
保持全局线程安全唯一值,对于创建并分配给colorID成员的每个CGColor对象,该值增加1.只有未记录的CGColorGetIdentifier()函数返回此值.(我猜测单调增加id值,它可以在设备与校准颜色查找之间进行转换时提高性能,反之亦然.)
我检查了CoreGraphics及其资源库.我发现只有ripc_GetColor(libRIP.A.dylib)函数调用CGColorGetIdentifier()函数.
调用CGColorGetIdentifier的堆栈;(希望能帮助推断colorID)
0 com.apple.CoreGraphics CGColorGetIdentifier + 0
1 libRIP.A.dylib ripc_GetColor + 112
2 libRIP.A.dylib ripc_DrawGlyphs + 1740
3 com.apple.CoreGraphics CGContextDelegateDrawGlyphs + 108
4 com.apple.CoreGraphics drawGlyphs + 284
5 com.apple.CoreGraphics CGContextShowGlyphsWithAdvances + 208
对于当前的颜色图形上下文操作,ripc_GetColor()计算当前笔触/填充颜色的一些变换,并使用此颜色的referenceID和colorID缓存这些变换.
因此,对于下一个图形上下文操作,ripc_GetColor()将先前缓存的当前引用和colorID值进行比较,以跳过已为最后一个图形上下文操作缓存的颜色转换.
我们知道在创建另一个对象时可以使用已发布对象的引用(内存地址).因此,仅检查引用将不足以使相同的颜色对象有效,但我们需要比较内容或某种哈希值.因此,我们可以为此目的使用唯一标识符值.
但是,标识符可以用于单个对象及其引用,因此仅比较ID就足够了.但是,使用了refs和id.我不认为工程师忽视了这么简单和至关重要的事情.
所以,我试图找出比较id和refs的必要性,同时只比较id就足够了.
是否遗留了以前的方法,所以不能完全放弃？
给定应用程序的 pid，是否有任何方法以编程方式检测该应用程序是否在 OSX 沙箱环境中运行？
理想情况下，我想知道某个地方是否有 API 调用，最好是用 C，而不是 Objective-C（对于守护进程，所以不使用 Cocoa），但如果没有，还有其他检查方法吗？
我不清楚以下内存管理含义:
NSDictionary* props = (__bridge NSDictionary*) CGImageSourceCopyPropertiesAtIndex(imageSource, 0, NULL);
由于该CGImageSourceCopyPropertiesAtIndex函数在名称中具有Copy,因此我拥有CFDictionaryRef并且必须将其释放.但是,既然它被投了一个NSDictionary,我就不能打电话了[props release].什么是对待这个的正确方法？
考虑到我有一个CFMutableArray使用以下函数调用创建的对象:
CFMutableArrayRef marray = CFArrayCreateMutable(kCFAllocatorDefault, 1, &kCFTypeArrayCallBacks);
根据CFMutableArray文档,的第二个参数CFArrayCreateMutable,这被称为capacity是"可以由新的数组被包含的值的最大数量.该阵列开始空并能长到这个数值(它可以具有更小) .传递0指定最大容量不受限制.该值不得为负数."
但是,如果我向我的新数组附加多个值,它会不断增长.我的意思是,如果新数组已经有一个值并且我附加了一个新CFArrayAppendValue(marray, newValue)值,则存储该值并且数组计数变为2,超过其容量.
那么,为什么会这样呢？我误解了文档吗？
如何在运行时以编程方式确定给定路径是 Mac OS X 上的网络路径还是本地路径？
例如： 1. /Volumes/abc/xyz （使用 smb 安装） 2. ../test/pqr （应用程序位于共享网络路径上，因此当前工作目录也是网络路径，因此相对路径也是网络路径）
就像在 Windows 上一样，下面的代码将确定 pPath 是否是网络共享路径（如 * 1. \TallyDT100\c\test\file.txt 2. z:\test\file.txt （当 z: 映射到时的网络路径）一些网络路径）。
UNIVERSAL_NAME_INFO * universalname = NULL; ///< for getting the universal path name of file on network share.
DWORD retval; ///< for getting the return value from WNetGetUniversalName
DWORD length = MAX_PATH_LEN; ///< length of universal name which would be made.
// The memory for getting the universal name information is allocated.
universalname = …我在应用程序中使用块执行许多异步执行.
但是如果某个事件出现在我的应用程序中,我需要杀死它们不是主线程的所有线程.
那么可以停止执行所有块吗？或者换句话说,杀死所有不是主线程的线程？
PS:我试图在NSOperationQueue中执行块,但是我的第一个操作并没有在以下时间开始.
multithreading objective-c core-foundation objective-c-blocks
在 macOS 10.12 中，NSURLCanonicalPathKey被添加到NSURL. 文档指出：
\n\n\nURL 的路径作为规范的绝对文件系统路径。
\n
除此之外，我看到的唯一其他文档/信息来自Swift 论坛帖子，其中指出：
\n\n\n\n\n您可能想查看 .canonicalPathKey (NSURLCanonicalPathKey)。在 Apple 平台上，许多标准 UNIXy 路径都存在于 /private/ 中，并具有来自根目录的相应符号链接。所以/etc/实际上是/private/etc/。如果您不\xe2\x80\x99t 规范化路径，您可能会因此而陷入困境。
\n
这对我来说似乎是一件大事，但令我惊讶的是它只在 10.12 中引入。我曾经只依赖NSURLPathKey或.path书签数据来解析 URL，但从来没有遇到过问题。
我现在应该在以前使用过的所有地方都使用规范路径\n标准路径值吗？
如果我将路径信息作为字符串存储在数据库中，我应该存储.pathor的值吗NSURLCanonicalPathKey？
如果我将 转换NSURL为字符串表示形式以在需要文件路径的 C/C++ 库中使用，我应该使用规范路径表示形式吗？
如果您要向用户显示文件的路径，是否应该显示规范路径？
与和NSURLCanonicalPathKey相比如何，它们似乎做了相同的事情或相反的事情......（？）URLByStandardizingPathURLByResolvingSymlinksInPath
这是在 macOS 10.14 上，我只考虑指向文件或文件夹的 URL。我知道书签数据可能应该存储在数据库中而不是路径中。
\n