問題タブ [automatic-ref-counting]

iPhone アプリを新しい ARC テクノロジーに移行しようとすると問題が発生します。コードを変換しようとすると、次のエラーが 29 回表示されます。

これは何を意味するのでしょうか？さらに重要なことに、どうすれば修正できますか? 前もって感謝します！

XCode 4.2 (ベータ 4) で提供される iOS マスター/詳細テンプレートを使用して、メモリ管理用の ARC を使用し、iOS 4.3 ターゲット用にコンパイルしています。

Instruments は私のコードですべて問題ないと報告していますが、UITableView 内の UIKit 内部タスク「_setupTableViewController」から 2 x 32 バイトのリークがあります。

これは、評価のためにアプリを提出する前に心配する必要がありますか? もしそうなら、呼び出しツリーが問題がdynlibのclass_createInstanceにあると言っているので、追跡して修正する方法についてのヒントは歓迎されます!

ARCコンパイラから次の警告が表示されます。

これが私がしていることです：

なぜこの警告が表示されるのですか？コンパイラがセレクターが存在するかどうかをチェックできないことは理解していますが、なぜそれがリークを引き起こすのでしょうか？そして、この警告が表示されないようにコードを変更するにはどうすればよいですか？

私は ARC を使用しています (いいえ、これは NDA ではありません)。とのインターフェースでivarを宣言しています

次に、プロパティを宣言します。

@property (nonatomic, weak) id<mySecretDelegateYouAreNotSupposedToSeeOnSO> itemDelegate;（ARCのため、割り当てではなく弱い）

私の実装ファイルでは、単純に合成します。@synthesize itemDelegate;

ただし、次のエラーが表示されます。

誰が何が悪いのか知っていますか？ご協力いただきありがとうございます。

ARC - 自動参照カウント

ARC では、 にキャストできなくなりましCGColorRefたid。ブリッジキャストを行う必要があることを学びました。clang docsによると：

ブリッジされたキャストは、次の 3 つのキーワードのいずれかで注釈が付けられた C スタイルのキャストです。

(__bridge T) opオペランドを宛先 type にキャストしますT。T が保持可能なオブジェクト ポインター型である場合、保持op不可能なポインター型である必要があります。が保持不可能なポインター型である場合T、op は保持可能なオブジェクト ポインター型である必要があります。そうしないと、キャストの形式が正しくありません。所有権の譲渡はなく、ARC は保持操作を挿入しません。

(__bridge_retained T) op保持可能なオブジェクト ポインター型である必要があるオペランドを、保持不可能なポインター型である必要がある宛先の型にキャストします。ARC はローカル値の通常の最適化に従って値を保持し、受信者はその +1 のバランスをとる責任があります。

(__bridge_transfer T) op保持不可能なポインター型である必要があるオペランドを、保持可能なオブジェクトポインター型である必要がある宛先の型にキャストします。ARC は、ローカル値の通常の最適化に従って、囲んでいる完全な式の最後で値を解放します。

これらのキャストは、オブジェクトを ARC の制御内外に転送するために必要です。保持可能なオブジェクト ポインターの変換に関するセクションの理論的根拠を参照してください。

__bridge_retainedorキャストを純粋に使用して、__bridge_transferARC に不均衡な保持または解放をそれぞれ出力させることは、不適切な形式です。

それぞれどんなシチュエーションで使うの？

たとえば、 の配列を受け入れるプロパティがありCAGradientLayerます。私の推測では、ここで使用する必要がありますが、なぜ使用する必要があるのか​​ (または使用しないのか) は明確ではありません。colorsCGColorRef__brige

私は次のような単純なボタンクラスを書いています：

Clangから次の警告が表示され[object performSelector:action]ます：

いくつかの調査の結果、セレクターは異なるメモリ要件を持つファミリに属する​​ことができることがわかりました。アクションが無効に戻ることを目的としているため、ARCに問題が発生することはなく、none家族に適している必要があります。

私が欲しいプリプロセッサコードの関連部分は、次のように見えます。

しかし、Clangに心配しないように伝えるために、どこにそれを置くのでしょうか？

注: これは、長い間修正されてきた一部の XCode ベータ バージョンのバグによるものです。ARC に問題がある場合、この質問と回答は役に立たないでしょう。

プロジェクトを手動参照カウントから ARC に移行していますが、問題に遭遇しました:保持プロパティのカスタム セッターが実際に保持されていることを確認するにはどうすればよいですか?

ではmyClass.h、プロパティを宣言しました: @property (retain) NSDate *date。__strongivarを手動で設定するか、自動生成するかは問題ではありません。

実装では、もちろん@synthesize date、カスタム セッターを実装しました (またはデモ Xcode プロジェクトをダウンロードするだけです)。

これは日付を保持していないようで、後でmessage sent to deallocated instanceアクセスしようとしたときに、newName が元の場所で (自動) 解放されたときに私に知らせますmyClass.date(Zombie が有効になっている場合、それ以外の場合は静かにクラッシュします)。

セッターを使用するように変更するとdate = [newDate copy]、エラーを回避できますが、実際には必要ありません。カスタム セッターの削除も機能しますが、明らかに望ましくありません。

ここで何が欠けていますか？保持プロパティのカスタム セッターが実際に ARC 環境で保持されるようにするにはどうすればよいですか? これは非常に基本的で一般的なタスクのように思われるため、非常に明白なことを見落としていると思います。

(注: ARC は LLVM の一部として公開されているため、これは Apple NDA の条件には該当しません)

編集:問題をデモする小さな Xcode プロジェクトを作成し、github にアップロードしました。気軽にダウンロードして遊んでみてください。私は機知に富んでいます (確かに、今日の機知は最高ではありませんが)。

編集: このサンプル プロジェクトでは、この問題は解決されています (受け入れられた回答を参照)。残念ながら、私が共有する自由がないより大きなプロジェクトでは、問題は解決しません。回避策として、合成されたセッターを使用して重複したstrongプロパティを追加しました (ivar は機能しません)。新しいカスタム セッターは次のようになります。

-viewDidLoadメソッドで初期化するivarNSArrayがいくつかあります。1つには文字列が含まれ、もう1つにはIBOutletsが含まれます。ただし、初期化すると、配列内のすべてのオブジェクトがスコープ外になり、メモリアドレスは0x0になります（Xcodeデバッガーによる）。ただし、同じオブジェクトを持つローカルNSArrayがある場合は、正常に機能します。ivarNSStringまたはNSDictionaryの初期化はどちらも正常に機能します。

コード：

アレイを使用しようとすると、EXC_BAD_ACCESSランタイムエラーが発生します。これはXcodeのバグですか、それともNSArrayについて何かが足りませんか？更新：私はARCを使用しています。ARCをオフにしてクリーンビルドを実行した後、この問題は発生しなくなりました。これはARCのバグですか？

何が問題だったのかわかりませんが、安定版のXcode（4.0.2）に切り替えて、何の問題もありませんでした。助けてくれてありがとう！

OS 10.7 のリリース ノートを見ると、自動参照カウント (ARC) を使用してメモリ管理を簡素化する方法がいくつかあります。私はまもなく新しい Cocoa プロジェクトに着手しようとしていますが、モデルを使用する価値があるかどうか疑問に思いました (私の理解では、ARC の使用と非使用を混在させることはできません)。

ジレンマは、新しいものを使用するか、後でデバッグ時間を大幅に節約できる可能性があるものを使用するかのようです。しかし、そうですか？誰かがそれをいじって、実際の利点を見つけませんでしたか?

最近、ARCを使用するように変換しました。しかし、私は今奇妙なクラッシュを起こしているので、クラッシュログは本当に役に立ちません。アプリケーションの初期化プロセスの1つ（サーバーからのデータの取得、解析、ビューの設定）中に、bad_accessを取得します。これは、デバイスからのエラーログです。

Etcetera、これが唯一の役立つ部分だと思います。XCodeでの実行からクラッシュさせると、mainでクラッシュし、main、UIApplicationMain、CFRelease以外のコールトレースが表示されません。

以前は、オブジェクトの過剰リリースについてコードを調べていましたが、現在ARCを使用しているため、これが当てはまるとは思えません。このようなエラーをどのように修正しますか？

編集：データを解析するためのコードは、GCDを使用する別のスレッドにあり、そこに私の唯一の@autoreleasepoolが存在します。

また、NSZombieEnabledを使用して実行すると、NSArrayMリリース呼び出しが発生します。残念ながら、それは私たちがクラッシュログで読んだものと同じなので、ここではまだ実際の進歩はありません...

編集：わかりました。ARCを使用せずに他のすべてのメモリエラーを修正すると、このエラーが再び発生しました。どうやらそれはARC関連ではないようです...