Objective-C ++をコンパイルすると、次の診断が得られます。
'MyClass' cannot be shared between ARC and non-ARC code; add a non-trivial copy assignment operator to make it ABI-compatible
コピーコンストラクタとデストラクタが欠落している場合にも、同様のエラーが発生します。必要なメソッドを追加するのは簡単ですが、特にコピーできないようにしたいクラスの場合は、意味がないことがよくあります。また、ARCコードと非ARCコードを混在させません（少なくとも意図的にではありません）。
なぜこのメッセージが表示されるのですか？すべてのC ++クラスに無意味なメンバー関数を記述せずにメッセージを取り除くことができますか？
これは、ARC がPOD構造および C++ クラス内の Objective-C オブジェクトを思いとどまらせるためです。これは、それらを含めるとメモリの管理があいまいになるためです。これは、Objective-C メンバーの前に修飾子を付けることで解決できます。これにより__unsafe_unretained、ARC はクラスから離れた場所に置くように指示されますが、メンバー オブジェクトのメモリを自分で管理しなければならないという厄介な立場に置かれます。また、内部リンケージを持つオブジェクトは警告の対象外であるため、クラスまたは構造体を非修飾でラップすることnamespace { }も同様に機能します。Objective-C オブジェクトをクラス メンバとして持つファイル (または複数のファイル) で ARC を絶対に使用する必要がある場合は、(警告が示すように) 適切なアクセス演算子を提供する必要があります。それ以外の場合は、ARC をオフにしてトラブルを回避してください。
制限は、ARC 仕様のこのセクションで言及されています。
ただし、自明でない所有権修飾型は非 POD と見なされます。C++11 の用語では、それらは自明にデフォルト構成可能、コピー構成可能、ムーブ構成可能、コピー代入可能、ムーブ代入可能、または破壊可能ではありません。ARC の下で自明でない所有権修飾メンバーを持つクラスを ARC の外部で使用することは、C++ の 1 つの定義規則に違反します。
その理由は次のとおりです。ARC では、Objective-C オブジェクトを C++ 構造体またはクラスのフィールドとして使用すると、ARC はデフォルト コンストラクター、コピー コンストラクター、デストラクタなどにコードを暗黙的に追加して、オブジェクトのメモリを管理します。田畑。構造体またはクラスにこれらのコンストラクター/デストラクターがない場合は、ARC が自動的に追加します。
これは、そのような構造体またはクラスが元々「POD」(特殊なコンストラクター/デストラクタを持たないことを意味する C++ 用語) と見なされていた場合、ARC はこれらの特殊なコンストラクター/デストラクタを暗黙的に追加することによって非 POD にすることを意味します。ただし、C++ では、POD 型と非 POD 型の扱いが異なる箇所があります。そのような元々 POD の構造体またはクラス宣言が非 ARC コードと ARC コードの両方から見られた場合、非 ARC コードはそれがまだ POD 型であると考える可能性があります。しかし、これは間違っています (ARC は、POD 以外にするメソッドを追加しました)。ARC 以外のコードが間違ったことを実行し、メモリ管理をバイパスする可能性があります。その結果、それは許可されない必要があります。