残りは

Memory Management

• CFGetAllocator
• CFGetRetainCount
• CFRelease
• CFRetain

Determining Equality

• CFEqual

Hashing

• CFHash

Miscellaneous Functions

• CFCopyDescription
• CFCopyTypeIDDescription
• CFGetTypeID
• CFShow

です。今回はCFEqualとCFType関係を扱います。

CFEqual

引数の二つのオブジェクトが同一かどうかを返します。 CFBooleanを扱ったときにすでに一度使いました。 Core Foundationには、FoundationにおけるisEqualTo***に該当するメソッドは一切なく、すべてのクラスはこのメソッドを使います。

同一性が何で決まるのかは ドキュメントを見ると

Equality is something specific to each Core Foundation opaque type.
同一性は、各Core Foundationオブジェクトごとに決まっている

とあります。そしてCFNumberとCFStringについて例が書いてあります。

two CFNumber objects are equal if the numeric values they represent are equal.
CFNumberの場合、数値が同じならイコールになる。

Two CFString objects are equal if they represent identical sequences of characters, regardless of encoding.
CFStringの場合、エンコーディングは関係なく、文字列として同じならイコールになる。

つまり、簡単にまとめると、同一性の判断は持っている値なりの表現を対象に行われる、ということになります。 コレクションクラスの場合は、コレクションが同じかどうかが条件となります。

以上のルールから、基本クラスの同一性を判断するための比較対象は次のようになります。

もう一つ、比較対象のみを見るためMutable型とImmutable型は区別されません。 そのため、CFArrayもCFMutableArrayも比較対象が同じであればイコールになります。

基本クラスの例を見てみましょう。

//CFString
{
    CFStringRef string1 = CFSTR("yes");
    CFStringRef string2 = CFSTR("yes");
    printf("string1 : string2 = %d\n", CFEqual(string1, string2));
}

//CFArray
{
    const void *values1[] = {CFSTR("a"), CFSTR("b"), CFSTR("c")};
    CFArrayRef array1 = CFArrayCreate(kCFAllocatorDefault, values1, 3, NULL);
    const void *values2[] = {CFSTR("a"), CFSTR("b"), CFSTR("c")};
    CFArrayRef array2 = CFArrayCreate(kCFAllocatorDefault, values2, 3, NULL);

    CFMutableArrayRef array3 = CFArrayCreateMutable(kCFAllocatorDefault,
                                                    3,
                                                    &kCFTypeArrayCallBacks);

    CFArrayAppendValue(array3, CFSTR("a"));
    CFArrayAppendValue(array3, CFSTR("b"));
    CFArrayAppendValue(array3, CFSTR("c"));

    printf("array1 : array2 = %d\n", CFEqual(array1, array2));
    printf("array1 : array3 = %d\n", CFEqual(array1, array3));

    CFRelease(array1);
    CFRelease(array2);
    CFRelease(array3);
}

//CFData
{
    const UInt8 bytes1[] = {0,1,2,3,4};
    CFDataRef data1 = CFDataCreate(kCFAllocatorDefault, bytes1, 5);
    const UInt8 bytes2[] = {0,1,2,3,4};
    CFDataRef data2 = CFDataCreate(kCFAllocatorDefault, bytes2, 5);

    printf("data1 : data2 = %d\n", CFEqual(data1, data2));

    CFRelease(data1);
    CFRelease(data2);
}

//CFNumber
{
    CFIndex one = 1;
    char onec = 1;
    float onef = 1.0;
    CFNumberRef number1, number2, numberf;
    number1 = CFNumberCreate(kCFAllocatorDefault, kCFNumberCFIndexType, &one);
    number2 = CFNumberCreate(kCFAllocatorDefault, kCFNumberCharType, &onec);
    numberf = CFNumberCreate(kCFAllocatorDefault, kCFNumberFloatType, &onef);

    printf("number1 : number2 = %d\n", CFEqual(number1, number2));
    printf("number1 : numberf = %d\n", CFEqual(number1, numberf));
    CFRelease(number1);
    CFRelease(number2);
    CFRelease(numberf);
}

//CFDictionary
{
    const CFTypeRef keys[] = {CFSTR("key0"), CFSTR("key1")};
    const CFTypeRef values[] = {CFSTR("value0"), CFSTR("value1")};

    CFDictionaryRef dictionary1;
    dictionary1 = CFDictionaryCreate(kCFAllocatorDefault,
                                    (const void**)keys,
                                    (const void**)values,
                                    2,
                                    &kCFTypeDictionaryKeyCallBacks,
                                    NULL);
    
    CFTypeRef getKeys[2];
    CFDictionaryGetKeysAndValues(dictionary1, getKeys, NULL);
    
    const CFTypeRef keys2[] = {CFSTR("key1"), CFSTR("key0")};
    const CFTypeRef values2[] = {CFSTR("value1"), CFSTR("value0")};

    CFDictionaryRef dictionary2;
    dictionary2 = CFDictionaryCreate(kCFAllocatorDefault,
                                     (const void**)keys2,
                                     (const void**)values2,
                                     2,
                                     &kCFTypeDictionaryKeyCallBacks,
                                     NULL);
    printf("dictionary1 : dictionary2 = %d\n", CFEqual(dictionary1, dictionary2));
    CFRelease(dictionary1);
    CFRelease(dictionary2);
}
    
//CFDate
{
    CFAbsoluteTime time1 = 12345;
    CFAbsoluteTime time2 = 12345;
    CFDateRef date1, date2;
    date1 = CFDateCreate(kCFAllocatorDefault, time1);
    date2 = CFDateCreate(kCFAllocatorDefault, time2);
    printf("date1 : date2 = %d\n", CFEqual(date1, date2));
    CFRelease(date1);
    CFRelease(date1);
}

実行結果はすべてtrueになります。

注目したいのは、CFNumberの例で、floatとintegerの比較がtrueになっています。

printf("number1 : numberf = %d\n", CFEqual(number1, numberf));

CFGetTypeID

CFGetTypeIDメソッドはあるオブジェクトがどのクラスのオブジェクトなのかを判定するための一意な値(ID)を返すメソッドです。

CFTypeID CFGetTypeID (CFTypeRef cf);

戻り値はCFTypeID型で、クラスごとにユニークな値を返します。 Core Foundationのオブジェクトは便宜上クラスと読んではいますが、正確には不透過型なのでgetClassNameのようなメソッドがありません。そのかわりにCFGetTypeIDが存在している、と考えると理解しやすいと思います。C言語には型を動的に判定する仕組が存在しないので、このような仕組みが導入されています。

CFEqualでは、あるオブジェクトとオブジェクトが同じクラスであるかどうかは判定できません。 この判定を行いたい場合にも、CFGetTypeIDメソッドを使います。

注意点としては、CFGetTypeIDが返すCFTypeIDの値は実装によって変わる可能性があるため、どのCore Foundationのバージョンでも常に同じ値を返すとは限りません。 そのため、CFGetTypeIDが返す実際の値に依存したコードを書いてはいけません。

{ClassName}GetTypeID

たとえば、あるオブジェクトがCFArrayのオブジェクトかどうか判定するにはどうすればいいのか。 Core Foundationのクラスは必ずClassName + GetTypeIDというメソッドを必ず持っているのでこれを使います たとえばCFStringはCFStringGetTypeIDを持っています。

以下のようにして使います。

CFTypeRef obj; //どのクラスのオブジェクトか分からない

CFTypeID typeID = CFGetTypeID(obj);
if (CFStringGetTypeID() == typeID){
    printf("obj == CFString object!")
}else if (CFNumberGetTypeID() == typeID){
    printf("obj == CFNumber object!")
}

Core Foundationの中で最も小さいクラス、CFNullはCFNullGetTypeIDメソッドのみを持っています。

typedef const struct __CFNull * CFNullRef;

CF_EXPORT
CFTypeID CFNullGetTypeID(void);

CF_EXPORT
const CFNullRef kCFNull;    // the singleton null instance

CFCopyTypeIDDescription

CFCopyTypeIDDescriptionは、CFTypeIDを渡すと、CFTypeIDのdescriptionを返してくれるメソッドです。メソッド名にCopyと付いているのでオーナーシップを持つことに注意しましょう。

CFStringRef CFCopyTypeIDDescription (
   CFTypeID type_id
);

基本クラスで実行してみると、現状ではそれぞれクラス名を返します。 しかし、ドキュメントにもデバッグ用と明記されているように、このメソッドが返す値に依存したコードを書いてはいけません。

CFTypeID typeIDs[6] = {
    CFStringGetTypeID(),
    CFNumberGetTypeID(),
    CFDataGetTypeID(),
    CFArrayGetTypeID(),
    CFDictionaryGetTypeID(),
    CFDateGetTypeID()
};

for (CFIndex i = 0; i < 6; i++) {
    CFStringRef typeIDDesc = CFCopyTypeIDDescription(typeIDs[i]);
    CFShow(typeIDDesc);
    CFRelease(typeIDDesc);
}

実行結果

CFString
CFNumber
CFData
CFArray
CFDictionary
CFDate

CFType型のオブジェクトを取得する

余談になりますが、最近ふとCFType型のオブジェクトを作成する方法を思いつきました。

ふと思いついてNSObjectのインスタンスをToll-free bridgingしてCFGetTypeIDしたら、CFTypeGetTypeID(っていうCFTypeのTypeIDを返すPrivate関数)と同じ値だった。つまりはそういうことだ

— Norihisa Nagano (@7gano) May 11, 2013

NSObject *object = [[NSObject alloc] init];
CFTypeRef cfType = (__bridge CFTypeRef)object;

そしてこのコードが正解かどうかは、CFCopyTypeIDDescriptionで型名を取得すれば分かります。

CFTypeGetTypeID()はプライベート関数です。

printf("%d\n", CFTypeGetTypeID() == CFGetTypeID(cfType));
CFStringRef typeIDDesc = CFCopyTypeIDDescription(CFTypeGetTypeID());
CFShow(typeIDDesc);
CFRelease(typeIDDesc);

実行結果

1
CFType

ドキュメントにも記述がありませんし、できたところで用途がありませんが、面白いですね。

ポリモーフィズム

クラスによって挙動が変わるが、インターフェイスは同じ、というのはオブジェクト指向ではポリモーフィズムと呼ばれます。

ポリモーフィズム(多態性)

プログラミング言語の型システムの性質を表すもので、プログラミング言語の各要素（定数、変数、式、オブジェクト、関数、メソッドなど）についてそれらが複数の型に属することを許すという性質を指す。

もし、CFShowがなく、クラスごとにCFNumberShow, CFStringShow , CFArrayShowのようなメソッドがあるとすると

CFShow(obj);

で済む処理が

    CFTypeID typeID = CFGetTypeID(obj)
    switch (typeID) {
        case CFNumberGetTypeID()
            CFNumberShow(obj);
            break;

        case CFStringGetTypeID()
            CFStringShow(obj);
            break;

        case CFArrayGetTypeID()
            CFArrayShow(obj);
            break;

        default:
            break;
    }

のように分岐だらけになってしまいます。実際、CFShowの実装はCFGetTypeIDが返す値をインデックスとした関数のポインタの配列があり、オブジェクトごとに違う関数を呼び出すようになっています。

CFTypeが持つメソッドのように、ポリモーフィズムに対応した関数をポリモーフィック関数と呼びます。

次回はCFHashを扱います。

CFData

CFDataはドキュメントによると、byte buffersを扱う(ラッパー)クラスである、Core Foundationのオブジェクトとして振る舞うことができるバッファである、と書かれています。 NSDataとToll-free bridging可能です。Mutable型のCFMutableDataがあります。

特に難しい点はありませんが、いくつか例を見ておきましょう。

{
    const UInt8 bytes[] = {0,1,2,3,4};
    CFDataRef data = CFDataCreate(kCFAllocatorDefault, bytes, 5);
    CFShow(data);
    CFRelease(data);
}

{
    UInt8 *bytes = malloc(sizeof(UInt8) * 10);
    memset(bytes, 1, sizeof(UInt8) * 10);
    CFDataRef data = CFDataCreate(kCFAllocatorDefault, bytes, 10);
   
    //CFDataCreate時にcopyされるので、ここでfreeしても大丈夫
    free(bytes);
 
    CFShow(data);
    CFRelease(data);
}

{
    UInt8 *bytes = malloc(sizeof(UInt8) * 10);
    memset(bytes, 1, sizeof(UInt8) * 10);
    CFDataRef data = CFDataCreateWithBytesNoCopy(kCFAllocatorDefault,
                                                           bytes,
                                                           10,
                                                           kCFAllocatorDefault);
                                                          
    //CFDataCreate時にcopyされないのでfreeすると
　　 //その後、開放済み領域にアクセスすることになりクラッシュする
    free(bytes);
    CFShow(data);
    CFRelease(data);
}

CFDataは通常、渡されたバッファを内部バッファにコピーします。 つまり、渡したバッファをfree()するまでの間は、二倍のメモリを使うことになります。 巨大なデータを扱うなど、これがメモリ管理上問題となる場合には

CFDataCreateWithBytesNoCopy

を使うと、バッファがコピーされません。この場合、バッファの管理をオブジェクトのメモリ管理と一緒に行う必要があります。 3番目の例はCFDataCreateWithBytesNoCopyを使い、かつオブジェクトが参照しているバッファを先にfree()しているため、実行するとクラッシュします。

CFRelease(data);
free(bytes);

としなければなりません。NoCopyという名前のメソッドは他にも多数存在しますので、覚えておきましょう。

修正した場合の実行結果

 <CFData 0x100107ff0 [0x7fff7b6bf110]>{length = 5, capacity = 5, bytes = 0x0001020304}
 <CFData 0x100107ff0 [0x7fff7b6bf110]>{length = 10, capacity = 10, bytes = 0x01010101010101010101}
 <CFData 0x10010a410 [0x7fff7b6bf110]>{length = 10, capacity = 10, bytes = 0x01010101010101010101}

CFDataのメソッドを眺めていて気付くのは、 NSData#writeToFile に準ずるメソッドがないことです。Core Foundationオブジェクトの永続化は後ほどやります。

CFDictionary

次に、CFDictionaryを見てみましょう。 CFDictionaryはkeyとvalueのペアの関連を管理するクラス、と説明されています。ペアのことをエントリーと呼びます。エントリーには順番という概念はありません。 Keyはユニークとして扱われるため、重複できません。 また、KeyとValueはCFArrayと同じくCFType以外のCの型も扱えますが、CFPropertyListでXMLを扱うときにはCFStringでなければなりません。 NSDictionaryとToll-free bridging可能です。 Mutable型のCFMutableDictionaryがあります。

連想配列、辞書、ハッシュと、いろいろな呼び方がありますが Pythonのdictionary型、JavaのHashMapクラス、RubyのHashクラスと同様のものです。

const CFTypeRef keys[] = {CFSTR("key0"), CFSTR("key1")};
const CFTypeRef values[] = {CFSTR("value0"), CFSTR("value1")};

CFDictionaryRef dictionary;
dictionary = CFDictionaryCreate(kCFAllocatorDefault,
                                (const void**)keys,
                                (const void**)values,
                                2,
                                &kCFTypeDictionaryKeyCallBacks,
                                &kCFTypeDictionaryValueCallBacks);
CFShow(dictionary);
CFRelease(dictionary);

実行結果

<CFBasicHash 0x100108010 [0x7fff7b6bf110]>{type = immutable dict, count = 2,
entries =>
  0 : <CFString 0x100001100 [0x7fff7b6bf110]>{contents = "key1"}
    = <CFString 0x100001140 [0x7fff7b6bf110]>{contents = "value1"}
  1 : <CFString 0x1000010e0 [0x7fff7b6bf110]>{contents = "key0"}
    = <CFString 0x100001120 [0x7fff7b6bf110]>{contents = "value0"}
}

一行目を見ると、CFDictionaryのオブジェクトを作ったのにCFBasicHashと出力されました。 つまりCFDictionaryの実態はCFBasicHashだということになります。CFBasicHashはPrivateクラスなので通常、直接は使えません。そのためドキュメントにも記述はありませんが、名前にあるとおりハッシュテーブルを扱うCore Foundationのクラスです。辞書の実装方法はいろいろとあるようですが、CFDictionaryはハッシュテーブルで実装されています。

ドキュメントにも

a dictionary uses a hash table to organise.

整理するのにハッシュテーブルを使う

と明記されています。

デバッグツールのInstrumentsを使っているとCFBasicHashをよく見かけますが、正体はこれです。

この実行結果の元となるアプリケーションでは、直接Core Foundationは使っていません。 それなのにCore Foundationのクラスがいくつも登場しています。このことから、Core Foundationが内部で多数使われているということが分かります。

CFBasicHashはCFDictionary以外でも使われていますので、後半のソースコードを見る章で扱います。 そもそもハッシュテーブルとは何かは、CFTypeのCFHashメソッドと関係するので、その時に扱います。

CFDictionaryCreateメソッドの引数

kCFTypeDictionaryKeyCallBacks
kCFTypeDictionaryValueCallBacks

は、CFArrayのときに使った

kCFTypeArrayCallBacks

と同じようなものです。

ためしに

dictionary = CFDictionaryCreate(kCFAllocatorDefault,
                                (const void**)keys,
                                (const void**)values,
                                2,
                                &kCFTypeDictionaryKeyCallBacks,
                                NULL);

とKeyCallBacksだけ渡してみると

<CFBasicHash 0x100108010 [0x7fff7b6bf110]>{type = immutable dict, count = 2,
entries =>
     0 : <CFString 0x1000010f0 [0x7fff7b6bf110]>{contents = "key1"} = <0x100001130>
     1 : <CFString 0x1000010d0 [0x7fff7b6bf110]>{contents = "key0"} = <0x100001110>
}

valueの値が出力されなくなります。

これは何が起こっているかといいうと、NSDictionaryを継承してdescriptionメソッドをオーバーライドしているのと同じことですね。 先に言っておくと、これはCore Foundationにおいて、メソッドオーバーライドに近い機能を実現するための仕組みです。 CFTypeの章のまとめで扱います。

もう一度、実行結果を見ると

entries =>
0 : <CFString 0x100001100 [0x7fff7b6bf110]>{contents = "key1"} =
     <CFString 0x100001140 [0x7fff7b6bf110]>{contents = "value1"}
1 : <CFString 0x1000010e0 [0x7fff7b6bf110]>{contents = "key0"} =
     <CFString 0x100001120 [0x7fff7b6bf110]>{contents = "value0"}

となっており、0, 1とエントリーに順番があるかのように見えますが、前述の通り順番を持っていませんので注意しましょう。もし順番に依存したコードを書いて特定の環境で上手く動作したとしても、他の環境での動かないでしょう。

key0, key1, value0, value1の順番を入れ替えて

const CFTypeRef keys[] = {CFSTR("key0"), CFSTR("key1")};
const CFTypeRef values[] = {CFSTR("value0"), CFSTR("value1")};

を

const CFTypeRef keys[] = {CFSTR("key1"), CFSTR("key1")};
const CFTypeRef values[] = {CFSTR("value1"), CFSTR("value0")};

としても、CFDictionaryのオブジェクトとしては同じものとなります。同じとはなにか、という話はCFEqualメソッドを扱うときに解説します。

CFDate

CFDateは日付を扱うクラスです。NSDateとToll-free bridging可能です。 CFDateCreateのドキュメントを見てみると

Creates a CFDate object given an absolute time.

CFDateRef CFDateCreate (
   CFAllocatorRef allocator,
   CFAbsoluteTime at
);
Parameters
at
The absolute time to convert to a CFDate object.

atには、absolute timeを渡す、とあります。

absolute timeはCFAbsoluteTimeGetCurrent関数を使って取得します。

CFAbsoluteTime CFAbsoluteTimeGetCurrent ();

Absolute timeは、ドキュメントを見ると

Absolute time is measured in seconds relative to the absolute reference date of Jan 1 2001 00:00:00 GMT. 2001/01 00:00:00 GMT(絶対基準)からの(相対)秒

と書いてあります。実際にCFDateオブジェクトを作ってみましょう。

CFAbsoluteTime time = CFAbsoluteTimeGetCurrent();
printf("time = %f\n", time);
CFDateRef date = CFDateCreate(kCFAllocatorDefault, time);
CFShow(date);
time = CFDateGetAbsoluteTime(date);
printf("time = %f\n", time);

CFRelease(date);

実行結果

time = 388368376.591624
2013-04-23 00:06:16 +0000
time = 388368376.591624

秒数からおよその日付を計算をしてみると

irb(main):001:0> 388368376 / (60 * 60 * 24)
=> 4495
irb(main):003:0> 4495 / 365.0
=> 12.315068493150685

12年と(12ヶ月 * 0.3) = 4ヶ月経過 2001 + 12 + 4ヶ月 = 2013年4月 なので合っています。Unix Timeの1970年始まりではないので注意しましょう。

日付の扱いは、CFLocale CFDateFormatterなど関係するクラスが他にもいくつかあります。 詳細は日付とロケールの章で扱います。

以上で基本クラスを簡単に使えるようになりました。 次回は基本クラスを対象に、CFTypeのメソッドを掘り下げます。

CFArrayとコレクションクラス

CFArrayとCFMutableArrayは順番を持った値の集まりを扱うクラスです。 値の集まりを以降、コレクションと呼びます。 コレクションを扱うクラスをコレクションクラスと呼びます。

Core Foundationには以下のコレクションクラスがあります

コレクションクラスが扱う値とは何か、ということですが、FoundationのNSArrayは(NSObjectを継承したクラスの)オブジェクトだけを扱います。ドキュメントにもobjectsと記載があります。しかし、CFArrayのドキュメントにはCFTypeのオブジェクトでなければならない、という記述はありません。

CFArrayに限らず、Core Foundationのコレクションクラスは

Collections Programming Topics for Core Foundation に

A collection can contain other Core Foundation objects, custom data structures, and primitive data values.
コレクションは、Core Foundationオブジェクト以外の独自のデータ構造、プリミティブ型も持つことができる。

とあるように、CFTypeのオブジェクト以外も扱えます。

そのため、NSArrayのドキュメントでは対象はobjectsと書かれているのに対して、Core Foundationのドキュメントではvaluesと書かれています。

たとえば CFArrayGetLastIndexOfValue という最後のindexの値を返すメソッドの定義を見ると

CFIndex CFArrayGetLastIndexOfValue (
     CFArrayRef theArray,
     CFRange range,
     const void *value
     );

const void *value となっています。

もし、CFTypeのオブジェクトのみを扱うのであれば

const CFTypeRef

となっているはずなのです。

NSArrayの

- (id)lastObject;

はid型を返すので、オブジェクトであることが明示されています。

以上の違いに注意しましょう。 しかし、CFTypeのオブジェクト以外を扱うにはいくつかの注意が必要です。 たとえばNSArrayのオブジェクトにToll-Free Bridgingしてdescriptionメソッドを呼ぶとクラッシュします。 ひとまず、続きはCFArrayの詳細を扱うことにして、ここでは簡単にCFTypeのオブジェクトのみを扱ってみます。

CFArrayはNSArrayとToll-Free Bridging可能です。iOS/MacでNSArrayを使わないアプリケーションはまずないと思うので、おなじみかと思います。 CFArrayも同様に、他のCore Foundationのクラスの戻り値、引数などでなにかと登場します。 まずは使ってみましょう。

const void *values[] = {CFSTR("A"),CFSTR("B"),CFSTR("C")};
CFArrayRef array = CFArrayCreate(kCFAllocatorDefault, values, 3, NULL);
CFShow(array);
CFRelease(array);

<CFArray 0x100107ff0 [0x7fff7b6bf110]>{type = immutable, count = 3, values = (
0 : <0x100001080]]>
1 : <0x1000010a0]]>
2 : <0x1000010c0]]>
)}

となりますが、CFStringがアドレス表示になっています。

0 : A
1 : B
2 : C

もしくは

A
B
C

と出力してほしいところです。

そこでドキュメントを見ると

CFArrayRef CFArrayCreate (
   CFAllocatorRef allocator,
   const void **values,
   CFIndex numValues,
   const CFArrayCallBacks *callBacks
);

引数、callBacksは

A pointer to a CFArrayCallBacks structure initialized with the callbacks for the array to use on each value in the collection.

コレクションのそれぞれの値に対して使われるコールバック関数で初期化されたCFArrayCallBacks構造体のポインタ。

This value may be NULL, which is treated as if a valid structure of version 0 with all fields NULL had been passed in.
NULLを渡すと、version = 0, それ以外はNULLの構造体を渡したとみなされる。

If the collection contains only CFType objects, then pass a pointer to kCFTypeArrayCallBacks (&kCFTypeArrayCallBacks) to use the default callback functions.
CFTypeオブジェクトのみを持つとき、kCFTypeArrayCallBacksのポインタを渡すとデフォルトのコールバック関数が使われる。

とあります。そこでNULLではなくて、デフォルトのコールバック関数が使われるkCFTypeArrayCallBacksのポインタを渡してみます。

array = CFArrayCreate(kCFAllocatorDefault, values, 3, NULL);

を

array = CFArrayCreate(kCFAllocatorDefault, values, 3, &kCFTypeArrayCallBacks);

とします。

すると出力が

(
    A,
    B,
    C
)

になります。これで伝統のプリントデバッグがはかどりそうです。 なぜこういう動作になるのかは、CFTypeのまだ登場していないメソッドが関係するので、CFTypeのメソッドまとめ編でやります。

Toll-Free Bridgingを使って

NSLog(@"%@", (__bridge NSArray*)array);

とすると同様に

(
    A,
    B,
    C
)

となります。

CFMutableArray

次はCFMutableArrayを使ってみましょう。 add,remove,atIndex,removeAllなど、配列処理でおなじみの処理が可能です。

CFMutableArrayRef array;
array = CFArrayCreateMutable(kCFAllocatorDefault,
                             0,
                             &kCFTypeArrayCallBacks);
CFArrayAppendValue(array, CFSTR("A"));
CFArrayAppendValue(array, CFSTR("B"));
CFArrayAppendValue(array, CFSTR("C"));

CFShow(CFSTR("print all"));
CFShow(array);

CFArrayRemoveValueAtIndex(array, 1);
CFShow(CFSTR("RemoveValueAtIndex:1"));
CFShow(array);

CFArrayRemoveAllValues(array);
CFShow(CFSTR("RemoveAllValues"));
CFShow(array);

CFRelease(array);

実行結果

print all
(
    A,
    B,
    C
)
RemoveValueAtIndex:1
(
    A,
    C
)
RemoveAllValues
(
)

CFNumber

CFNumberは数を扱うクラスです。 NSNumberと同じ、と考えておよそ問題ありませんが違いとしてはByteSize、TypeというCの数値型に”より近い”メソッドがあることです。たとえばCFNumberIsFloatTypeというメソッドがあります。

printf("CFIndex Value\n");
CFIndex value = 123;
CFNumberRef number;
number = CFNumberCreate(kCFAllocatorDefault,
                        kCFNumberCFIndexType,
                        &value);
printf("numberType = %ld\n", CFNumberGetType(number));
printf("byteSize = %ld\n", CFNumberGetByteSize(number));
printf("isFloatType = %d\n", CFNumberIsFloatType(number));

NSInteger getValue;
CFNumberGetValue(number, kCFNumberCFIndexType , &getValue);
printf("getValue = %ld\n", getValue);

printf("\nFloat Value\n");

float floatValue = 0.123;
CFNumberRef floatNumber;
floatNumber = CFNumberCreate(kCFAllocatorDefault,
                        kCFNumberFloatType,
                        &floatValue);

printf("numberType = %ld\n", CFNumberGetType(floatNumber));
printf("byteSize = %ld\n", CFNumberGetByteSize(floatNumber));
printf("isFloatType = %d\n", CFNumberIsFloatType(floatNumber));

float getFloatValue;
CFNumberGetValue(floatNumber, kCFNumberFloatType, &getFloatValue);
printf("getValue = %f\n", getFloatValue);

CFRelease(number);
CFRelease(floatNumber);

実行結果

CFIndex Value
numberType = 4
byteSize = 8
isFloatType = 0
getValue = 123

Float Value
numberType = 5
byteSize = 4
isFloatType = 1
getValue = 0.123000

CFBoolean

CFBooleanはBoolean値を扱うクラスです。 ドキュメントを見ると、CFNumberを継承しているかと思いきや、していませんので注意しましょう。
Derived from CFPropertyList : CFType

定義は少ししかありませんので、すべて見てみましょう。

typedef const struct__CFBoolean * CFBooleanRef;

CF_EXPORT
const CFBooleanRef kCFBooleanTrue;
CF_EXPORT
const CFBooleanRef kCFBooleanFalse;

CF_EXPORT
CFTypeID CFBooleanGetTypeID(void);

CF_EXPORT

Boolean CFBooleanGetValue(CFBooleanRef boolean);

Core Foundationのクラス群の中でも特殊で、create/copyメソッドがありません。 つまりCFBooleanを自分で作ることはできません。 それでもCFBooleanGetTypeIDがあることが重要です。同様のクラスにCFNullがあります。 TypeIDについては後ほど扱います。

次のコードでできることのほぼすべてです。

CFShow(kCFBooleanTrue);
CFShow(kCFBooleanFalse);

printf("true = %d\n", CFBooleanGetValue(kCFBooleanTrue));
printf("false = %d\n", CFBooleanGetValue(kCFBooleanFalse));
printf("CFBooleanGetTypeID = %ld\n", CFBooleanGetTypeID());

実行結果

<CFBoolean 0x7fff7b6bfa30 [0x7fff7b6bf110]>{value = true}
<CFBoolean 0x7fff7b6bfa40 [0x7fff7b6bf110]>{value = false}
true = 1
false = 0
CFBooleanGetTypeID = 21

CFNumberCompareメソッド

比較メソッドであるCFNumberCompareを見ておきましょう。

CFComparisonResult CFNumberCompare (
   CFNumberRef number,
   CFNumberRef otherNumber,
   void *context
);

戻り値は小さい < 、同じ = 、大きい > を表す以下の定数です。

typedefCF_ENUM(CFIndex, CFComparisonResult) {
    kCFCompareLessThan = -1L,
    kCFCompareEqualTo = 0,
    kCFCompareGreaterThan = 1
};

CFIndex one = 1, two = 2;
CFNumberRef number1, number2;
number1 = CFNumberCreate(kCFAllocatorDefault, kCFNumberCFIndexType, &one);
number2 = CFNumberCreate(kCFAllocatorDefault, kCFNumberCFIndexType, &two);

CFComparisonResult comparisonResult;
comparisonResult = CFNumberCompare(number1, number2, NULL);
printf("comparisonResult = %ld\n", comparisonResult);

comparisonResult = CFNumberCompare(number2, number2, NULL);
printf("comparisonResult = %ld\n", comparisonResult);

comparisonResult = CFNumberCompare(number2, number1, NULL);
printf("comparisonResult = %ld\n", comparisonResult); 

CFRelease(number1);
CFRelease(number2);

実行結果

comparisonResult = -1
comparisonResult = 0
comparisonResult = 1

CFBooleanの比較メソッド

専用のメソッドはありません。 CFBooleanの比較は、まだ登場していませんが、CFEqualメソッドを使います。しかし行えるのは同じかの判定のみで、大小関係は判定できません。 また、そもそもオブジェクトは二個しかないので == 演算子を使っても同じことができます。

printf("kCFBooleanTrue : kCFBooleanFalse %d\n", CFEqual(kCFBooleanTrue, kCFBooleanFalse));
printf("kCFBooleanFalse : kCFBooleanFalse %d\n", CFEqual(kCFBooleanFalse, kCFBooleanFalse));
printf("kCFBooleanTrue : kCFBooleanTrue %d\n", CFEqual(kCFBooleanTrue, kCFBooleanTrue));

printf("kCFBooleanTrue : kCFBooleanFalse %d\n", kCFBooleanTrue == kCFBooleanFalse);
printf("kCFBooleanFalse : kCFBooleanFalse %d\n", kCFBooleanFalse == kCFBooleanFalse);
printf("kCFBooleanTrue : kCFBooleanTrue %d\n", kCFBooleanTrue == kCFBooleanTrue);

実行結果

kCFBooleanTrue : kCFBooleanFalse  0
kCFBooleanFalse : kCFBooleanFalse  1
kCFBooleanTrue : kCFBooleanTrue  1
kCFBooleanTrue : kCFBooleanFalse  0
kCFBooleanFalse : kCFBooleanFalse  1
kCFBooleanTrue : kCFBooleanTrue  1

CFStringCompare

CFStringにもcompareがあります。

//kCFCompareLessThan
printf("a : b %ld\n", CFStringCompare(CFSTR("a"), CFSTR("b"), 0));

//kCFCompareEqualTo
printf("b : b %ld\n", CFStringCompare(CFSTR("b"), CFSTR("b"), 0));

//kCFCompareGreaterThan
printf("b : a %ld\n", CFStringCompare(CFSTR("b"), CFSTR("a"), 0));

// kCFCompareCaseInsensitive 大文字小文字を無視
printf("A : a %ld\n", CFStringCompare(CFSTR("A"), CFSTR("a"), kCFCompareCaseInsensitive));

実行結果

a : b -1
b : b 0
b : a 1
A : a 0

ドキュメントを見ると、compareOptionsには0を渡すとデフォルトの動作とあります。 オプションはいろいろありますが、大文字小文字を区別しない kCFCompareCaseInsensitive を使ってみました。結果、0 (== kCFCompareEqualTo)になっています。 文字列比較についてはCFStringの詳細で詳しく扱います。

CFTypeに準共通のメソッド

CFTypeには準共通のメソッドがある、と覚えておくとなにかと便利です。 簡単に言えば、いくつかのパターンがあり、Core Foundationが明確な規則によって作られていることが分かります。 Imutable型とMutable型を扱ったので、いくつかのメソッドを見てみると

CFArrayCreate
CFArrayCreateCopy
CFArrayCreateMutable
CFArrayCreateMutableCopy

CFStringRef
CFStringCreate(WithCString, WithBytes, …)
CFStringCreateCopy
CFStringCreateMutable
CFStringCreateMutableCopy

のように、Mutable型を持つクラスはすべて

“ClassName” + Create (+ With**)
“ClassName” + Create + Copy
“ClassName” + Create + Mutable
“ClassName” + Create + MutableCopy

というメソッドを必ず持っています。

それぞれ、NSObjectで言うところの、init、copy, mutableクラスのinitializeメソッド、mutableCopy、に該当します。 覚えておくとコーディングスピードが少し上がります。

Core Foundationでは、Mutable型を持つクラスは現在9つあります。

Compareメソッド

大小関係があるクラス(CFString,CFNumber,CFDate)は ClassName + Compare という比較メソッドを持っています。

CFStringCompare
CFDateCompare
CFNumberCompare

戻り値はすべてCFComparisonResultです。

これはコレクションクラスを使うとソートが可能、ということです。 CFMutableArrayを使ってCFNumberをソートしてみましょう。

void CFArraySortValues (
   CFMutableArrayRef theArray,
   CFRange range,
   CFComparatorFunction comparator,
   void *context
);

第三引数のCFComparatorFunction comparatorには対象オブジェクトのcompareメソッド(の関数のポインタ)を渡します。

CFMutableArrayRef array;
array = CFArrayCreateMutable(kCFAllocatorDefault,
                             0,
                             &kCFTypeArrayCallBacks);

CFIndex one = 1, two = 2, three = 3;
CFNumberRef number1, number2, number3;
number1 = CFNumberCreate(kCFAllocatorDefault, kCFNumberCFIndexType, &one);
number2 = CFNumberCreate(kCFAllocatorDefault, kCFNumberCFIndexType, &two);
number3 = CFNumberCreate(kCFAllocatorDefault, kCFNumberCFIndexType, &three);

CFArrayAppendValue(array, number2);   
CFArrayAppendValue(array, number1);
CFArrayAppendValue(array, number3);

CFRelease(number1);
CFRelease(number2);
CFRelease(number3);


CFShow(CFSTR("print all"));
CFShow(array);

CFArraySortValues(array,
                  CFRangeMake(0, CFArrayGetCount(array)),
                  (CFComparatorFunction)CFNumberCompare,
                  NULL);

CFShow(CFSTR("sorted array"));
CFShow(array);

CFRelease(array);

print all
(
    2,
    1,
    3
)
sorted array
(
    1,
    2,
    3
)

ソートできました。

ちなみに、Foundationで同様の処理を書くと

NSMutableArray *array;
array = [NSMutableArray arrayWithArray:@[@2, @1,@3]];
[array sortUsingSelector:@selector(compare:)];
NSLog(@"array = %@", array);

となります。 Clang 3.1からの新しいObjective-CリテラルとARCがいかに強力なのか分かります。

コレクションクラスとCompareは、CFEqual, CFHash,CFComparatorFunctionなどまだまだ関係するものがいくつかあるので後ほど登場します。

今回はCFArray, CFNumberを例にコレクションクラスの紹介と、Compareメソッドを使ってみました。次回は残りの基本クラスを扱います。

これからはいくつかのクラスを例に、CFTypeの他のメソッドを理解していきましょう。 話を進めるには基本クラスを知っておく必要があるので、 先に簡単に見ていきましょう。

基本クラスとは何か

何をして基本というのか、よく使われるとか、これがないと成立しないとか、いろいろ定義はあると思いますが、本連載では、CFPropertyListを継承しているクラスを基本クラスと言うことにします。

第二回でCFStringのドキュメント見たときに
Derived from CFPropertyList Reference : CFType Reference
という記述がされているのにCFPropertyList Referenceを後回しにしました。

実はこの記述は非常に重要で、CFPropertyListで扱えるクラスであることを表しています。 CFPropertyListはプロパティリストを扱うためのクラスです。 そして、CFPropertyListを使ってファイルに書き出しできるのは以下のクラス(のオブジェクト)だけなのです。

CFData, CFString, CFArray, CFDictionary, CFDate, CFNumber(CFBoolean)

これら基本クラスはCore Foundationで何かを行う際に頻出しますので、先に簡単に把握していきましょう。

Toll-Free Bridging

基本クラスとその機能を把握しやすくするために先に書いておくと、Core FoundationにはToll-Free Bridgingという仕組みがあり、Core Foundationのオブジェクトのいくつかはキャストするだけで(！) Foundation.framework(以下、Foundation)のNS***というクラスのインスタンスとして使うことができます。基本クラスはすべてToll-Free Bridgeに対応しています(表参照)。

たとえば、CFStringはNSStringとおよそ同じもの、と考えて大丈夫です(が、CFStringにしかないメソッドもあるのでこれが重要！)。 表の右側(Foundation)を見ると、iOS/Macの開発で頻繁に使うものばかりであることが分かります。
Toll-Free BridgingはCore Foundationがなぜ存在するのか、ということに関わってくる重要な仕組みなので、後ほどじっくり扱います。

Imutable型とMutable型

CFNumber、CFDate以外には、それぞれ変更可能なMutable型が存在します。反対に変更不可能な型をImutable型といいます。

Mutable型もToll-Free Bridgingに対応しています。機能もおよそ同等です。

CFMutable”ClassName”は、”ClassName”を継承している、とドキュメントにありますがこの連載では、単純にCFTypeを継承している、と書きます。

CFString

CFStringは文字列を扱うためのクラスです。

なんといってもCFSTRをよく使います。 CFSTRの注意点としては、retain/releaseが必須ではないことです。 Foundationでも

NSString *string = @"String";
[string release];

とは書きません。これと同じです。 オブジェクトはアプリケーション終了時に開放されます。

もう一点、ドキュメントを見ると

The argument of the macro must be a constant compile-time string—text enclosed in quotation marks.

このマクロの引数はコンパイル時の定数文字列(“”で囲われたテキスト)でなければならない。

とあります。それを強制している部分が面白いので見てみましょう。 まず、定義を見ると

#if TARGET_OS_WIN32 || TARGET_OS_LINUX
#undef __CONSTANT_CFSTRINGS__
#endif

#ifdef __CONSTANT_CFSTRINGS__
#define CFSTR(cStr)  ((CFStringRef) __builtin___CFStringMakeConstantString ("" cStr ""))
#else
#define CFSTR(cStr)  __CFStringMakeConstantString("" cStr "")

#endif

(iOS/Mac環境では)TARGET_OS_WIN32 || TARGET_OS_LINUX は偽なので

はundefされていません。どこかで(ソースコードを見ると、CFInternal.hで！)定義されています。

そのためこのマクロが定義になります。

#define CFSTR(cStr)  ((CFStringRef) __builtin___CFStringMakeConstantString ("" cStr ""))  

__builtin___CFStringMakeConstantString

は

__builtin_  +  __CFStringMakeConstantString

に分解できます。__builtin_ は関数をビルトイン関数化するGCCの拡張命令です。 __CFStringMakeConstantStringは関数名です。
https://github.com/opensource-apple/CF/blob/master/CFString.c#L1664 に実装があります。

ビルトイン関数化すると、ドキュメントにはCの標準ライブラリ関数と同等になる、と書いてあります。最適化されたり、宣言がある.hファイルをインクルードしなくても使えるようになったりします(警告は出ますが)。 Core Foundationのソースコードの中でいくつか登場するので、連載後半のソースコードからCore Foundationを読み解く章で扱います。

たとえば、CFSTR(“yes”)と書いたとします。

"" "yes" ""

って何になるの？ということですが、両隣の”"を”A”だとしてみると

“A”"yes”"A”の途中にスペースがある書き方です。

printf("A" "yes" "A");
=> AyesA

つまり、”AyesA”と等価になります。こういう書き方ができるわけです。

たとえ

const char *cStr= "yes";
printf("A" cStr "A");

と書いたとしてもシンタックスエラーになるため、”"で囲われた文字列(文字列リテラル)を直接書くことしかできません。

"A""yes""A"

という書き方は応用すると、コード表記上、改行を入れたいときに便利です。

printf("A"
"yes"
"A");

と書くことができます。

同様の表記がNSStringでもできるので

NSLog(@"Core""Foundation");
NSLog(@"Core" "Foundation"); //この書き方は読み間違えるかもなのでよくなさそう
NSLog(@"Core"@"Foundation"); //これもOK
NSLog(@"Core"
      @"Foundation"); //これもOK

という書き方ができます。

次にCFShowStrを見ておきましょう。 CFStringの属性をログに出してくれるデバッグ用メソッドです。

CFShowStr
Prints the attributes of a string during debugging.
void CFShowStr (   CFStringRef str 
);

CFShow(CFSTR("yes"));
CFShowStr(CFSTR("yes"));

を実行すると

yes

Length 3
IsEightBit 1
HasLengthByte 0
HasNullByte 1
InlineContents 0
Allocator SystemDefault
Mutable 0
Contents 0x100000f70

という風に、CFStringの詳細を出力します。

注意点としては、デバッグ用なので、このメソッドが返す結果に依存したコードを書いてはいけません。 そういうコードを書いてしまうと、いつか動かなくなる可能性があります。Core FoundationもiOS/MacのSDKがバージョンアップするたびに変更が行われているからです。 これはCFShowも同様なので注意しましょう。

ドキュメントでは、デバッグ中にブレークポイントで止まっているときに

(gdb) call (void) CFShowStr(string)

と使う方法が紹介されています。

余談になりますが、CFSTRのドキュメントのRelated Sample Codeに注目すると、Core Audioばかり！

Related Sample Code

• AddMusic
• iPhoneExtAudioFileConvertTest
• iPhoneMixerEQGraphTest
• iPhoneMultichannelMixerTest
• SpeakHere

つまり、Core Foundationの知識はCore Audioな人には必須ということになります。

Core AudioとCore Foundation

なぜCore AudioのサンプルコードでCore Foundationが使われているのか？ それは、Core AudioがC言語のインターフェイスを持つフレームワークだからです。Core AudioとCore Foundationを使えば、同じC言語だけで書くことができるため、相性がよいわけです。 Foundationが使われていれば、C++の世界に持っていくことができなくなります(Objective-C++には持っていけますが)。 Core Audioはハードウェアに近いフレームワークであるため、C++で実装されています。そのため、以前はほとんどのサンプルコードがC++で書かれていました。C++を好むプログラマはC, C++の世界で完結させたいのでFoundationではなくCore Foundationを使うわけです。 SpeakHereでは、実際にCFStringをC++のクラスで使っています。 (Foundationを使うとNSAutoreleasePoolが必要になる、というのもあります)

iOS/Macで必要となる基本機能が(一番下の)C言語のレイヤーで実現されている、というのがCore Foundationの存在理由の一つなのです。 もっと付け加えるならば、Core Foundationはオープンソースなので(！！！)、iOS/Macとそれ以外の環境でのクロスプラットフォームなライブラリを作りたい場合、Core Foundationを使う、という選択肢があるでしょう。実際、Linuxで動く Core Foundationがあるようです。 CFSTRマクロを見たときに

#if TARGET_OS_WIN32 || TARGET_OS_LINUX

という定義がありました。

また、これはWindows版Safariがあることと関係しています。 Windows版Safariのパッケージ内にCoreFoundation.dllというものがあり、これはCoreFoundation.frameworkと同等のものです。つまり、Core FoundationはWindowsでも動く、ということです。 また、Androidで動くCore Foundationもあるようです。

Core Foundationのクラスは(特にメモリ管理、コレクションクラスにおいて)カスタマイズ性が考慮されており、ライブラリをごりっと書く、という用途が想定されているように思われます。この辺の仕組みはこの連載のハイライトになりそうな予感がしています。

CFStringを少し扱っただけで、いろいろなトピックが出てきてしまいました。 CFStringを理解することは、そのままC言語、そしてNSSringの理解へとつながり、それはiOS/Macの文字列処理を理解することとなります。そのため、後ほどじっくり扱います。

今回はCFStringを例に基本クラスの概要と余談を書きました。
次回はその他の基本クラスを扱います。

今回はメモリ管理に関するメソッド

Memory Management

• CFGetRetainCount
• CFRelease
• CFRetain

を扱います。メモリ管理とは、メモリ領域の確保と破棄、ここではオブジェクトの生成と破棄のことです。
CFTypeを継承するクラスすべてで必要になるため非常に重要です。
この3つのメソッドと”Allocator” (あとで扱います)の解説のためだけに
Memory Management Programming Guide for Core Foundation
というドキュメントがあります。

おそらく実務上、Core Foundationで一番使うのはこのメソッド群です
とくにCFReleaseはCore Foundationって何？という人も目にしたことがある可能性が高いと思います。

たとえば、CGPathRefを扱ったことがあれば

CGMutablePathRef path = CGPathCreateMutable();
...
CFRelease(path);

といったコードを書いたことがあると思います。

CGMutablePathRef? CFじゃないのに関係あるの？と思うかもしれませんが
CGPathのドキュメントを見ると
Derived from CFType Reference
と書いてあるのです。

Quartz 2D Programming Guide: Overview of Quartz 2D には

Quartz uses the Core Foundation memory management model, in which objects are reference counted.
QuartzはCore Foundationのリファレンスカウント方式のメモリ管理モデルを使う。

と書いてあります。つまり、CFTypeのメモリ管理メソッドはCore Foundationだけにとどまらず、iOS/Macのいろいろなフレームワークで使うことになりますので、そこそこ複雑なアプリケーションを作る際には必須の知識です。

ちなみに、QuartzというiOS/Macの基礎(Foundation)を支えているフレームワークがCore Foundationを基礎としていることから、Core FoundationがまさにFoundationのCoreである、ことが分かります(まずはFoundation.frameworkを支えている、というのが正しいですが、この辺の話は後ほど)。

リファレンスカウント方式のメモリ管理

さて、もう「リファレンスカウント方式のメモリ管理」という言葉が出ましたが、Core Foundationはこの方式を使います。
iOS/Macのアプリケーションを一個でも作ったことがあれば、同じ方式でメモリ管理を行ったことがあるはずなのです。
リファレンスカウント方式のメモリ管理モデルというのは、Objective-Cの(NSObjectの)retain/releaseと同じ方式です。

先にこれから説明することをコードで見てみましょう。

NSObject *object = [[NSObject alloc] init]; //retain count = 1
[object retain]; //retain count = 2
[object release]; //retain count = 1
[object release]; //retain count = 0 開放される

(通常はこんなコードは書きませんが)
と同じことを、Objective-Cのメッセージ式ではなく、C言語の関数で行うだけです。

CFTypeを作ることは(通常)できないので、CFStringで書くと

CFStringRef string;
string = CFStringCreateWithCString(kCFAllocatorDefault,
                                   "Core Foundation",
                                   kCFStringEncodingUTF8);

printf("%ld\n",CFGetRetainCount(string)); //1

CFRetain(string);
printf("%ld\n",CFGetRetainCount(string)); //2

CFRelease(string);
printf("%ld\n",CFGetRetainCount(string)); //1

CFRelease(string); //0 開放される

となります。

Objective-Cの場合と同じですね。

ルール

Core Foundationのメモリ管理では、Objective-Cと同様のルールがあるので押さえておきましょう。
オーナーシップ・ルールがCore Foundationにもあります。

3つを簡単に書くと

1. オブジェクトを作ったらオーナーシップ(所有権)を持つ
2. どこかからゲットしたオブジェクトに対してはオーナーシップを持たない。ゲットした以降も使うならオーナーシップを持つ。
3. オーナーシップを持ったら、必要なくなったときにオーナーシップを破棄する。

となります。それぞれの文の主語はオブジェクトを使うオブジェクトです。
オーナーシップを持つには、CFRetain、破棄するにはCFReleaseを使います。

また、1.の作るとはどういうことかというと、クリエイト・ルールというものがあり

次の二つです。

1. メソッドにCreateという文字があったら、オーナーシップを持つ
2. メソッドにCopyという文字があったら、オーナーシップを持つ

Objective-Cでは、copy, mutableCopy, new, init**というメソッドはretainCountが1のインスタンスを返すというルールがありますが、これと同等のものです。
たとえば、サンプルコードの
CFStringCreateWithCString
がこれにあたります。

ルールのまとめ

以上を簡単にまとめると

1. CreateもしくはCopyという名前がついたメソッドでオブジェクトを作ったら、必ず対でCFReleaseする。
2. Copy/Createじゃないメソッドでオブジェクトをゲットしたら、何もしない。
3. ただし、2.でゲットしたオブジェクトが無くなるとまずい場合はCFRetainする。その場合、必要なくなったらCFReleaseする。

以上のルールも、Objective-Cのメモリ管理とほぼ同じですね。
これは偶然ではなくて、Objective-Cで使うNSObjectとCFTypeはじつは双子みたいなものなのです。
その辺の話も後ほど。

Core FoundationとARC

NSObjectのretainとreleaseをサンプルコードで書きましたが、今はARC時代。もう書きませんよね。

ですが、Core Foundationは現在ARCに対応していないのでCFRetain/CFReleaseを自分で書く必要があります。
ARCとCore Foundationのメモリ管理の関係、Objective-Cのメモリ管理については
「エキスパートObjective-Cプログラミング」
が非常に詳しいです。
少々難しいですが、iOS/Macのアプリケーションを開発するなら必ず必要になる大事な部分なので、二ヶ月ぐらいかけてもいいので読みましょう。

次回はこの先を説明するために、Core Foundationの基本的なクラスをいくつか紹介します。

MOSA Software Meeting2012
で「Audio Unitの世界」というセッションをやったのですが
そのビデオが発売になっています。

Audio Unitでサイン波を鳴らす初歩から、AUGraphでEffectを使うのあと、Sampler Unitを使ってドラムマシンを作るところまで解説しています。
ビデオの他に、キーノートと以下のような資料(39ページのPDFファイル)も付いています！

買ってください。

セミナーの内容
■概要
ソフトウェア、ハードウェアの進化によってiPhoneはポケットの中の音楽スタジオと言っても過言ではないほど、パワフルなオーディオ処理環境となっています。特にiOS 5から多くのAudio Unit(エフェクト、サンプラー機能)が追加されたことは見逃せません。
このセッションでは、これらのAudio Unitの使い方と簡単なサンプラーの開発方法をデモを交えながら解説しています。

■対象者（技術レベル）
・簡単なiOSアプリケーションをApp Storeでリリースする程度の開発経験がある方
・C言語およびObjective-Cの知識がある方
・AVFoundationを使って、録音・再生機能を実現できる方
(Audio Unitを使ったことがあるほうが望ましいですが、最初に簡単に解説します)

Creates an immutable string from a constant compile-time string.

CFStringRef CFSTR (const char *cStr);

となっています。戻り値はCFStringRefです。

CFStringRefは文字列を扱うものですが
まずはドキュメントを見ます。

Derived from CFPropertyList Reference : CFType Reference
と書いてあります。

Derived from なので、CFPropertyListとCFTypeから派生しているということですね。
CFPropertyListのドキュメントを見ると
Derived from CFType
と書いてあります。
以上からCFStringRefは、CFTypeを継承していることが分かります。

CFPropertyListも重要なのですが、ここでは先にCFTypeにフォーカスします。

CFType

CFTypeのドキュメントを見ると
Derived from None

その下のOverviewを見ると

All other Core Foundation opaque types derive from CFType.

CFTypeを除くすべてのCore Foundationの不透過型はCFTypeから派生している

と書いてあります。つまり、CFTypeがオブジェクト指向言語で言うところのルートクラスです。
ただ、CFTypeのドキュメントを見ると、一言も”クラス”とは書いてないことに注意しておきましょう。
メソッド、インスタンス変数という言葉も出てきません。
書いてあるのは、opaque type(不透過型)だけです。

opaque type 不透過型

不透過型というのは、たとえば、CFStringRefの定義を見ると

typedef const struct __CFString * CFStringRef; 

とあるのですが、構造体__CFStringの定義はどこにもなく、隠されています。
そのため、構造体のメンバーを直接変更することが(やろうと思えばできるけど、一応)出来なくなっており、メンバーをもし変更可能としたいなら、たとえばset/get用の関数を別途用意することで、オブジェクト指向で言うところのカプセル化を実現することができるのです。

このパターンはiOS/MacのC言語のインターフェイスを持つフレームワークで頻出します。
Core Audioでもよく使われます。たとえばAudioUnit型はOpaqueAudioComponentのポインタ型でOpaqueAudioComponentという構造体の定義は隠されています。

CFTypeに話を戻すと
Core Foundation Design Concepts: Polymorphic Functions

に次のような一文があります。

CFType is analogous to a root class in object-oriented languages because its functions can be reused by all other objects.
CFTypeはオブジェクト指向言語のルートクラスに似ている。その関数は他のすべてのオブジェクトで再利用できるからだ。

なので、厳密にはCFTypeはルート”クラス”ではないのですが、そう考えた方が分かりやすいです。
そのため、以降この連載ではCFTypeはルートクラスであると見なします。
同時に、そこから派生した不透過型もクラスと見なします。
たとえば

CFStringRefはCFTypeRefを継承したクラス

というような記述をします。

クラスと見なすのですから、不透過型を引数に取る関数も、メソッドと呼んだほうがいいでしょう。

CFStringRefのメソッド、CFStringCompareは、文字列同士を比較します

というような記述をします。

CFTypeのメソッド

CFTypeは

先ほどの一文に

その関数は他のすべてのオブジェクトで再利用できるからだ。

とあるように、Core Foundationのオブジェクトすべてで使用できる重要なメソッドを持っています。

Memory Management
* CFGetAllocator
* CFGetRetainCount
* CFMakeCollectable
* CFRelease
* CFRetain

Determining Equality
* CFEqual

Hashing
* CFHash

Miscellaneous Functions
* CFCopyDescription
* CFCopyTypeIDDescription
* CFGetTypeID
* CFShow

CFMakeCollectableは(廃止予定の)ガーベージコレクション関係のメソッドなので除外すると、以上、10個のメソッドがあります。

前回も使ったCFShowが、本当にすべてのCore Foundationオブジェクトに対応できるのか試してみましょう。CFStringRefとCFArrayRefのインスタンスを渡してみます。

できていますね。
次回はその他のメソッドを見ていきましょう。

ふと、Core Foundationって面白そうだなーと思い、困らない程度には知っているけど、深くは知らないし、Foundation Frameworkに無い便利クラスがあるとは知っているけど使ったこと無いものも多い。ではBlogでも書いてみよう、と思い始め調べはじめました。
そこで、Core Foundationとその周辺の話を書いていきます。

見通しとしては

• CFTypeRef周りで数回
• Core Foundationは現在、約45個のクラスがあるので、それぞれのクラスを扱うと45回
• CFNetwork.frameworkというのが居るので10回ぐらい
• Quartz 2D(Core Graphics)のオブジェクトモデルがCore Foundation Object形式なので、その辺をやると数回

の計70回ぐらいの連載になって、数年やっても終わらないと思います。

Core Foundationを理解するメリットはなにか

僕も詳しくないのであれですが、現段階で言えることは以下

• iOSの開発でCF****(たとえばCFError)とか出てくるので、何かNS***じゃないものがあるのは知っているけど、よく分かっていない人は、その辺の事情が分かってDebugとかが捗るかも
• Quartz 2Dをやる人はCGPathRefとかをCFReleaseしたことがあると思いますが、これが何なのか分かる(その他CFTypeRefを継承したオブジェクトが基本のフレームワークが多数ある)
• 何かの機能を実現したいとき、これ簡単にできないのかなー、と思ってNS***とかを調べて無かったら自作していた人は、CF***も調べるようになって、その機能が見つかるかも

さて、何かを調べ始めるとしたらまずはAppleのドキュメントを読むでしょう。

最初に読むのは
Core Foundation Design Concepts
でしょう。

あとは、コンパイル、実行する環境を作ります。
Xcodeで、ずばりCore Foundationというテンプレートがあるのでこれを使います。
iOSじゃなくてOS X Applicationの方を選びます。

次にTypeでCore Foundationを選びます。

NS***を使いたいときもあるし、Foundationの方が何かと捗りますが、Core Foundationで一回プロジェクトを作ってみます。

次はHello, Worldしたくなると思うのでやってみましょう。

Core Foundationでプロジェクトを作ると、もうできています。
⌘ + Rしてください。iOSと違ってシミュレーターの起動とか無いので一瞬です。

みたいにHello, Worldと出れば成功です。

プロジェクトを眺めると見るべきものはmain.cぐらいしかありません。
main.cってことは、これObjective-Cは全然関係ないですね。.cなのでPure Cです。
もう一回言うとObjective-Cは全然関係ありません。

興味があるのはこの一行です。

CFShow(CFSTR("Hello, World!\n"));

CFShowは

void CFShow(CFTypeRef obj);

となっていて、ドキュメントを見ると
Prints a description of a Core Foundation object to stderr.
と書いてあります。
“Core Foundation object”
という用語が出ました。

ということは、CFSTRでCore Foundation objectが作られて、それのdescriptionがHello, World!だということですね。
引数はCFTypeRef型なのでCFTypeRefがCore Foundation Object型っぽいですね。

今回は導入編なのでこれぐらいにして、次回からCore Foundation Objectって何？とかやっていきます。

というiOSデベロッパーのカンファレンスで一個セッションをやります

conferenceWithDevelopersはiOS開発に携わる、すべての開発者に向けたカンファレンスイベントです。 登壇者によるiOSにまつわる技術トークとエンジニアの交流をメインの目的としています。

僕は
13:15~14:00『けっこーすごいよ、Audio Unit』
というセッションで、Audio Unitを使って、何か楽器っぽいものを作る方法を解説します。
iOS 5以降の新しい話なので、Core Audio本には載っていない内容になります。

無料のイベントでまだ空きがあるみたいなので、興味がある方はおこしください。

そういえば、Core Audio本は売り切れたみたいです。
改訂の予定は今のところありませんし、増刷もしないみたいなので、欲しい方は本屋で見つけたら買っておいた方がいいと思います。
今、Amazonだと1万円ぐらいしますね。

【夜間/中級】iOS開発セミナー： iOS6時代のCore Audioの基礎

前回、前々回のセミナー
「iPhone Core Audio入門セミナー：Core Audioの概要から”ボイスメモ”アプリケーションの作成まで」
「iPhone Core Audio入門セミナー：波形編集アプリを作ろう」

が好評いただけたようで
またまた続編をやらせていただくことになりました。
続編とはいいつつも今回は
iOS 6が出て、Core Audioも進化してきているので
基礎編を更新したものがやりたいなと思っていました。
そこで
「iOS6時代のCore Audioの基礎」
ということで、Core Audioの全容を話させてもらいます。

Core Audio本と同じく、Core Audioの全容をシンプルなサンプルコードをベースに解説していきます。
その中でiOS 6までに増えたフレームワーク、APIなどを一緒に説明していきます。
iOS 5でかなり機能が増えたので、そこが中心になると思います。

対象者は
・簡単なiPhoneアプリケーションを作成したことがある方
・C言語およびObjective-Cの知識がある方
です。

有料ですが、ぜひお越しください。

日 時：2012年10月26日（金）18：30～21：30（休憩含む）

会 場：大橋会館 （東京都目黒区）

地下鉄田園都市線「池尻大橋」駅下車（渋谷駅より１つ目）。東口から駅前商店街を直進。徒歩約5分。

主 催：特定非営利活動法人MOSA

http://www.mosa.gr.jp/?p=5359