}NSNumberの0と、NSIntegerの0NSNumberの0(@0)は、0ではなく、0という値を持つNSNumberのインスタンスです。NSIntegerの0は、nilと同じ0です。コーディングの中でのnilnilに対するメソッド呼び出し結果はnilであるObjective-C的な記法は、このnil呼び出し仕様に強く依存しています。initという書き方も、allocが失敗してnilになっても、initが問題なく処理されることを前提としています。alloc]init]これはObjective-Cの特徴であり文化なので、これを生かしたコーディングをすることで、よりObjective-Cらしいコードになります。@"";ただし、他の多くの言語(Java等)では、nil(に相当するNULL等)に対して呼び出しを行うとエラーになります。Exceptionを見て涙することにになります。nilに対するブロック呼び出しは落ちるブロックはNSObjectに近い扱いができますが、NSObjectではありません。ブロックがnilの場合、それに対する呼び出しを行うと落ちるので要注意です。意図通りnilに対する呼び出しは安全ですが、必ずしもプログラマの意図通りの動作をするとは限りません。nilで落ちないからこそ、nilでも正しく動くコーディングスタイルが必要になります。Cで使用するメモリ管理の方式で、従来プログラマが明示的に行っていた参照数管理をコンパイラが自動的に行う物です。リファレンスカウンティングGCに近いですが、頑張るのがランタイムではなく、コンパイラな点が異なります。Coutingという名前のとおり、「参照数のカウント」を自動的に行い、参照数が0になったオブジェクトを自動的に解放してくれます。(このカウントアップをretain、カウントダウンをreleaseと呼びます)この「参照している」という状態の反対が、「何も指していない」というnilです。pointer)普通に参照を定義すると、それは強参照となり対象をretainします。ARCは強参照が一つでもある限りオブジェクトを解放しないので、不要なオブジェクトを指すポインタには明示的にnilを設定して解放する必要があります。実際には変数のスコープとオブジェクトグラフの構造により、あまり意識せずに解放は行われます。pointer)__weakを指定して作成した参照は、弱参照となり対象をretainしません。pointerにnilを設定します。これは、nilに対する呼び出しが安全に行えるObjective-Cだからこそ生きる機能です。pointer)もう一つの弱参照がunsafe_unretainedで、弱参照となり対象をretainしません。ARCは強参照が0になると弱参照があってもオブジェクトを解放し、unsafe_unretainedには何もしません。呼ぶと危険なのでunsafeです。Fundation系で遭遇します。二つのオブジェクトが相互に強参照をもってしまった場合、そのオブジェクトをARCが解放することはありません。ガベージコレタクのように孤立した循環参照を見つけて解放とかは一切ないので、プログラマの責任で循環参照を回避する必要があります。基本的な対策として、相互に参照するオブジェクトには常に主従関係を考え、従->主の参照はweakポインタにしておきます。主従関係を考えるのが難しい場合には、解放したいタイミングで参照ポインタをnilにする必要があります。Blockによる循環参照Blockはスコープ内で必要な変数への参照を持ちます。そのため、ブロック内で不用意にブロックの所有者を参照してしまうと循環参照となります。対策は、、、一言で書くのがちょっと難しいです。あるケースとしてブロック内でselfを参照してしまうケースについては、weakなselfを作ることで対応できます。これは本当にケースバイケースです。Ota@tomohisaotaかつてiOSエンジニアでしたが、今はnodejsばかり書いています。最近はデータ解析系の話が増えてきました。upLoginユーザーは見つかりませんでした。