3

最後に静的ライブラリとして出荷される客観的な C フレームワークを開発しています。しかし、そのライブラリを実際のアプリケーションに (静的ライブラリを追加することによって) リーク ツールに統合すると、いくつかのメモリ リークが存在することがわかります。

シナリオの例を次に示します。

@implementation Test

@synthesize testNumber

+(Test) createTestInstance {

    Test *test = [[Test alloc] init];
    test.testNumber = [[NSDecimerNumber alloc] initWithInt:1];

    return test;
}

-(void) dealloc {
    [testNumber release];
}

@end

dealloc で testNumber 変数を解放しても、Leaks ツールで alloc 位置でメモリ リークが発生します。ここで何が問題になる可能性がありますか?

また、これはユーザーが呼び出すために提供されるライブラリであるため、これらの変数をライブラリ コードから解放することはベスト プラクティスですか?

ありがとうございました

4

1 に答える 1

11

ここに2つの問題があります。が保持プロパティである場合testNumber、次のステートメントでそれを過剰保持しています。

test.testNumber = [[NSDecimerNumber alloc] initWithInt:1];

alloc-initとプロパティアクセサーの両方がオブジェクトを保持しています。したがって、次のようになります。

test.testNumber = [[[NSDecimerNumber alloc] initWithInt:1] autorelease];

testNumberメソッドでリリースする必要があることを言及する必要はありませんdealloc。

また、オブジェクトcreateTestInstanceを作成するための便利なコンストラクターであり、オブジェクト所有権ポリシーTestに従って自動解放されたオブジェクトを返す必要があることを理解しています（「alloc」、「new」、「copy」、または「mutableCopy」で始まる名前のメソッドのみがあなたが所有するオブジェクト）：

+ (id)createTestInstance {

    Test *test = [[[self alloc] init] autorelease];
    test.testNumber = [[[NSDecimerNumber alloc] initWithInt:1] autorelease];

    return test;
}

最後に、@ Josh Caswellが提案しているように、コンビニエンスコンストラクターはid特定のクラスの代わりに戻る必要があります。Objective-Cプログラミング言語から：

「<ahref="http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ObjectiveC/ Chapters / ocAllocInit.html＃// apple_ref / doc / uid /TP30001163-CH22-SW14"rel="nofollow">制約と規則。"</p>

また、サブクラス化を適切selfに処理するために、ハードコードされたクラス名の代わりにインスタンスをalloc-initする必要があります（これはクラスメソッドであるため、ここではクラスオブジェクト自体を指します）。self

于 2011-06-16T12:43:43.430 に答える