11

次のようなクラスを含む構造体を作成してみました。

struct my_struct
{
    NSString *string;
    // more fields
};

驚いたことに、Objective-C++ では ARC を有効にしてこれを許可していました。
文字列をどのように管理しますか？
各割り当てで簡単に保持できますが、リリースが問題です。
release を含むデストラクタを追加できますが、これにより構造体が自明ではなくなります。
これを保持または解放しないようにすることもできますが、そうするには unsafe_unretained が必要です。

私の観察では、これを使用しても何もクラッシュしませんが、ここで実際に何が起こるか知りたいです。

4

1 に答える 1

9

ARCドキュメントの4.3.5を参照してください。

4.3.5。構造体と共用体の所有権資格のあるフィールド

プログラムは、C構造体またはユニオンのメンバーが所有権を修飾されたタイプであると宣言した場合、形式が正しくありません。

理論的根拠：結果の型はC ++の意味で非PODになりますが、Cは集計の存続期間を管理するための非常に優れた言語ツールを提供しないため、単にそれらを禁止する方が便利です。void*または__unsafe_unretainedオブジェクトを使用してこれを管理することは引き続き可能です。

この制限は、Objective-C++には適用されません。ただし、自明ではない所有権修飾型は非PODと見なされます。C++ 11の用語では、それらは自明なデフォルトの構築可能、コピー構築可能、移動構築可能、コピー割り当て可能、移動割り当て可能、または破棄可能ではありません。ARCの下で、所有権の資格を持つメンバーを持つクラスをARCの外部で使用することは、C++の単一定義規則に違反します。

理論的根拠：Cとは異なり、所有権が修飾されたサブオブジェクトに必要なすべてのARCセマンティクスを、クラスの（デフォルトの）特殊メンバー関数のサブオペレーションとして表現できます。これらの機能は重要になります。これは、クラスに自明でないコピーコンストラクタと自明でないデストラクタがあるという明白でない結果をもたらします。これが通常ARCの外部では当てはまらない場合、そのタイプのオブジェクトはABIと互換性のない方法で渡されて返されます。

すべての警告を読んだ場合は、ObjC++でこれを行うことは強くお勧めしません。いかなる場合でも、ObjC++を広範囲に使用しないことを強くお勧めします。これは、純粋なObjCと純粋なC++が相互に通信するのに役立つブリッジ言語です。多くの問題があります。ObjC ++をARCと組み合わせると、ObjCを例外安全にするために、ObjCでは発生しない時間とスペースの両方のパフォーマンスコストが発生します。これらの種類のObjC++固有のデータ構造を定義すると、非ObjC ++コードおよび非ARCコードとの対話が困難になります（ARCの外部ではこれを使用できないことに注意してください）。ARCから無料で入手できるものの多くは、メモリ管理について再度心配する必要があるため、突然難しくなります（すでに発見しているように）。

純粋なObjCレイヤーを構築します。純粋なC++レイヤーを構築します。薄いObjC++レイヤーを作成して、2つを結び付けます。ObjCオブジェクトを構造体に配置しないでください。また、パブリック構造体には絶対に配置しないでください（つまり、それを定義する単一のObjC ++オブジェクトの外部に表示されます）。

于 2012-06-01T14:28:29.527 に答える