Objective-CプロジェクトにC ++を埋め込む方法

このトピックは、Objective-CプロジェクトにC ++を埋め込む方法に関する記事を翻訳したもので、成功と失敗の両方の興味深いソリューションを説明しています。 元の記事：

www.philjordan.eu/article/strategies-for-using-c++-in-objective-c-projects



だから

Objective-CプロジェクトにC ++を埋め込む方法

急いでいる場合、ヘッダーファイルを破損せずにObjective-CクラスにC ++オブジェクトを埋め込む問題に直接行きたいので、純粋なObjective-Cからインクルードできるように、記事をPimplヘッダーまでスクロールできます。 このソリューションは、〜95％のケースで使用できます。 残りには、問題のより深い分析とそれを解決するための追加の方法が含まれています。

Objective-CとC ++を混在させる理由

通常、iOまたはMacでのプログラミングにObjective-Cを使用すると、プロジェクトにC ++を挿入する必要がある場合によく遭遇しました。 現在のタスクに最適なライブラリがC ++で記述されている場合もあれば、C ++で問題をより簡単に解決できる場合もあります。 最も一般的な例はC ++テンプレートであり、重複した標準コードを記述する必要がありません。 それほど明白ではありませんが、Objective-Cがオブジェクト指向すぎることがあります。 「すべての人がすべてのオブジェクトである」ための異端のように聞こえますが、重要なデータ構造では、オブジェクトの向きが面倒で、Sysn構造が弱すぎることがよくあります。 C ++を使用するのが適切です。



また、Objective-Cは、ガベージコレクターなどがある場合、メモリ管理の点でも非常に積極的です。 STL（およびその新しい拡張機能shared_ptr）を使用すると、この問題を忘れたり、少なくともコンストラクター/デストラクタに集中したり、リリースや保持でコードを乱雑にしないことができます。 もちろん、これは好みの問題であり、状況によって異なります。 自動メモリ管理は、重要なデータ構造を持つコードや、アルゴリズム的に複雑なコードに役立ちます。



Objective-CとC ++を混在させるもう1つの理由は、C ++プロジェクトからObjective-C関数を呼び出す必要がある場合の反対の状況です。 一般的な例は、ゲームまたはエンジンをAppleプラットフォームに移植することです。 そのような場合、以下で説明する手法を適用することもできます。



最後に、C ++を使用してパフォーマンスを改善できます。 Objective-Cメッセージの柔軟性は、最新のランタイムで使用されるキャッシングテクニックを考慮しても、ほとんどのC ++仮想関数の実装と比較していくらかのコストを課します。 Objective-Cオブジェクトには、同等の高速非仮想C ++関数がありません。 最適化のために、これは重要な要素となります。

共通の分母につながる：C

これらの2つのプログラミング言語を1つのプロジェクトで使用する方法の1つは、これらを完全に分離し、純粋なCを介して相互作用できるようにすることです。 C ++ライブラリを使用するコードは.cppファイルに転送され、インターフェイスはCヘッダーファイルで宣言され、C ++パーツはextern“ C”関数を使用してこのインターフェイスを実装し、インターフェイスにアクセスするコードCは純粋なObjective-C（.m）です。



これは単純なケースではうまく機能しますが、シェルを作成する必要がある可能性が高くなります。 オープンCインターフェイスを使用して動的にロードされたC ++ライブラリの経験がある人なら、これをよく知っています。



現在、Objective-CのほぼすべてがGCCまたはclangを使用してコンパイルされています。 どちらのコンパイラーもObjective-C ++をサポートしています。つまり、言語を混合するより便利な方法があるということです。

Objective-C ++およびヘッダーファイルの問題

一見すると、Objective-C ++方言の使用は最も簡単なアプローチのように見えます。 これは、C ++とObjective-Cを1つのコンパイラにマージした結果であり、その信頼性の高い実装はGCCとclangの両方にあります。 Objective-CとC ++の違いを考えると、GCCプログラマーは退屈な仕事をしています。 しかし、.mファイルの名前を.mmに変更してC ++ファイルとして宣言し始めるとすぐに、それほど簡単ではないことがわかります。



ヘッダーファイルとCプリプロセッサは、長年C、C ++、Objective-Cプログラマの悩みの種であり、これらの言語を混在させると事態はさらに悪化します。 Objective-CクラスのSTLライブラリのマップコンテナー（辞書、連想配列）を使用するとします。 私の知る限り、AppleのFoundationフレームワークには、ツリー上に構造的に構築されたソート済みマップは含まれていません。 したがって、クラスにメンバー変数を作成します。

#include <map> @interface MyClass : NSObject { @private std::map<int, id> lookupTable; } // ... @end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、std :: map <int、id>は、C ++をサポートするコンパイラーに対してのみ意味があり、＃includeの後のみであるため、このヘッダーファイルはObjective-C ++ファイルからのみインポート（#import）できます。 そして、このクラスを使用するコードはすべてObjective-C ++に変換する必要があります。 さらにチェーンに沿って、残りのヘッダーファイルも変換する必要があり（.mm）、プロジェクト全体で変換する必要があります。



場合によってはこれで問題ありません。 それにもかかわらず、ライブラリを1か所で使用するためだけにプロジェクト全体またはその大部分を変更するのは、面倒で冗長です。 さらに、C ++を知っているObjective-Cプログラマーの中でプロジェクトで唯一のユーザーである場合、これは良い考えではありません。 さらに、純粋なC ++ Cコンパイラでコードをコンパイルするときに問題が発生する可能性がありますが、これがまったく問題なく実行されることはほとんどありません。 さらに、これは他のObjective-Cプロジェクトでコードを自動的に再利用できないことを意味します。



ほとんどの場合、純粋なObjective-CまたはC ++のコードを活用する方法は、必要な場所でのみObjective-C ++を使用することです。 これを完璧に行うには、試してみる必要があります。

自分の足を撃つ：void *

目標がヘッダーファイルからC ++からすべてを削除することであることが明らかになります。 型を非表示にする典型的なCの方法は、voidへのポインターです。 ここでは、もちろん、これも機能します：

 @interface MyClass : NSObject { @private //    std::map<int, id>* void* lookupTable; } // ... @end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テーブルが使用されるコードのこれらの場所では、明示的な型キャストを使用する必要があります：static_cast <std :: map <int、id> *>（lookupTable）または（（std :: map <int、id> *）lookupTable）非常に迷惑になります。 クラスメンバの実際の型が変更された場合、すべての型変換を手動で変更する必要があります。これにより、間違いを起こす可能性が大幅に増加します。 メンバーの数が増えると、すべての正しい型を覚えることができなくなり、その結果、静的型と動的型の両方の不利な点が生じます。 このメソッドを使用してクラス階層のオブジェクトを操作することは、火災を伴う危険なゲームであり、同じオブジェクトへのポインターA *とB *が異なる表現を持っていることが判明する可能性がありますvoid *



あなたはもっとうまくやれる。

条件付きコンパイル

型情報を失うのは悪いことですが、C ++型付きフィールドはObjective-Cコードから使用され、純粋なObjective-Cコンパイラはそれらの存在のみを知る必要があるため（メモリを正しく割り当てるため）、コードの2つの異なるバージョンを作成しないでください？ Objective-C ++は_cplusplusプリプロセッサシンボルを定義しているため、この実装についてはどうですか：

 #ifdef __cplusplus #include <map> #endif @interface MyClass : NSObject { @private #ifdef __cplusplus std::map<int, id>* lookupTable; #else void* lookupTable; #endif } // ... @end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

glyいですが、作業はずっと簡単です。 C ++標準は、クラスへのポインタとvoidへのポインタが同じメモリ位置を持つことを保証しません（オブジェクトはもちろん同じです）が、Objective-C ++はGNU / Apple標準ではありません。 実際には、仮想関数へのポインタのみがvoid *に変換するときに問題を引き起こします。これを実行しようとすると、コンパイラは大声で誓います。 問題が解決しない場合は、Cスタイルのキャストの代わりにstatic_cast <>を使用できます。



Cは暗黙的にvoid *を暗黙的に他のポインターに導きます。そのため、Cの#ifdefセクションを、struct MyPrefix_std_map_int_idなどの複雑であるが一意の認識可能な名前を持つ構造体へのポインターに置き換えることが望ましい場合があります。 コンパイラに応じて、正しい型定義に拡張するマクロを定義することもできます。

 #ifdef __cplusplus #define OPAQUE_CPP_TYPE(cpptype, ctype) cpptype #else #define OPAQUE_CPP_TYPE(cpptype, ctype) struct ctype #endif // ... #ifdef __cplusplus #include <map> #endif @interface MyClass : NSObject { @private OPAQUE_CPP_TYPE(std::map<int, id>, cpp_std_map_int_id)* lookupTable; } // ... @end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この方法では、条件付きの#include C ++ヘッダーを避けることができず、C ++を知らない、または嫌いな人を混乱させる可能性があります。 はい、それはあまり見えません。 幸いなことに、他の解決策があります。

抽象クラス、インターフェース、およびプロトコル

多くのC ++プログラマーは、純粋な仮想関数、したがって抽象クラスに非常に精通しています。 JavaやC＃などの他の言語には、実装の詳細を意図的に隠す明示的な「インターフェース」の概念があります。 この場合、同じパターンを使用できます。



Objective-Cの最近のバージョンは、構文ではないにしても、本質的にJava / C＃インターフェイスに類似したプロトコルをサポートしています。 ヘッダーファイルのプロトコルでクラスのパブリックメソッドを宣言し、指定されたプロトコルを実装する特定のクラスをクローズドソースコードで宣言して記述できます（したがって、C ++とObjective-Cは分離されます）。 これはインスタンスメソッドに対しては機能しますが、プロトコルを介してクラスを直接インスタンス化することはできません。 そのため、新しいオブジェクトのメモリ割り当てと初期化をクラスファクトリまたは関数Cに委任する必要があります。さらに悪いことに、プロトコルはある意味でクラスに直交しているため、リンクを宣言すると、外観が異なります。

 id<MyProtocol> ref;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

予想される代わりに：

 MyClass* ref;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてが機能しますが、理想的でもありません。

Objective-Cの抽象クラス

では、抽象クラスはどうでしょうか？ この言語では、これらに対する直接的な慣用的なサポートはありませんが、一般的なNSStringでさえ抽象的であり、単に使用するだけではこれを理解することは不可能です。 問題を解決する1つの代替方法は、すべてのメソッド宣言を取得し、それらをすべてそのようなクラスに入れることです。 不完全なクラス記述に関するコンパイラーの警告に耐える必要があります。 実行時に、存在しないメソッドを呼び出そうとすると、例外がスローされます。 もちろん、状況を説明する特別な例外をスローするこれらのメソッドの擬似実装を作成できます。



ほとんどの言語では、インスタンスを作成するには、特定のクラスを知るか、クラスファクトリに委任する必要があります。 興味深いことに、NSStringクラスにallocおよびinitメッセージを直接送信でき、NSStringから継承されたクラスのインスタンスを取得できます。 initメッセージは、initが送信されたself以外のオブジェクトを返します。たとえば、NSStringのallocを再定義してNSCFStringを呼び出すことができます。ここではクラスファクトリはNSStringです。 これを自分で行う場合、特定のクラスが抽象に使用するすべてのinit *メソッドを定義する必要があります。そうしないと、抽象メソッドを使用する人には見えません。



したがって、抽象クラスですべてのメソッドを宣言し、Objective-C ++クラスから継承することは、ヘッダーファイルおよびこのクラスを使用するユーザーにとって間違いなく最も無塵なソリューションですが、同時に最も時間がかかり、追加のクラス、擬似メソッドが必要ですおよびinitの重要な実装。



ただし、C ++プログラマーは、このような問題のエレガントな解決策を見つけました。 大規模なC ++プロジェクトの重大な問題の1つは、ヘッダーファイルの依存関係に関連するコンパイル時間の劇的な増加です。 そのような場合、通常、それを使用するプログラマからクラス内部を隠します。 まったく同じソリューションをObjective-C / C ++のジレンマに適用できます。

mpl子

Pimpl-「実装へのポインター」または「プライベート実装」の略。 このイディオムは非常に単純です。 構造体の実装のオープンな説明がオープンヘッダーファイルに追加され、通常、接尾辞Implが付いたパブリッククラスの名前を使用して、規則によって異なります。 この構造体には、パブリッククラスヘッダーファイルから非表示にする必要があるすべてのメンバーが含まれます。 クラス変数の構造体へのポインターを追加し、.cppファイル（この場合は.mm）で構造体のメンバーを定義します。 コンストラクター（より正確には、-init *）では、new演算子を使用して、構造体のインスタンスを作成し、クラス変数に割り当て、-deallocでdeleteが呼び出されることを確認する必要があります。

 MyClass.h: // ... struct MyClassImpl; @interface MyClass : NSObject { @private struct MyClassImpl* impl; } //   ... - (id)lookup:(int)num; // ... @end MyClass.mm: #import "MyClass.h" #include <map> struct MyClassImpl { std::map<int, id> lookupTable; }; @implementation MyClass - (id)init { self = [super init]; if (self) { impl = new MyClassImpl; } return self; } - (void)dealloc { delete impl; [super dealloc]; } - (id)lookup:(int)num { std::map<int, id>::const_iterator found = impl->lookupTable.find(num); if (found == impl->lookupTable.end()) return nil; return found->second; } // ... @end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

構造体の進行中の宣言は有効なCコードであるため、後で構造体に明示的または暗黙的なC ++コンストラクターまたは親クラスが含まれていることが判明した場合でも、すべてが機能します。 クラスのパブリックメソッドは、ポインターを介して構造体にアクセスし、new / deleteを使用して作成と削除を行います。



実装、オープンクラスメソッドが持つ機能の量に依存します。 場合によってはObjective-Cメッセージの転送を避ければパフォーマンスを改善できますが、C ++メソッドがObjective-Cクラスにメッセージを送信する必要がある場合に発生する可能性のある問題に留意してください。



MyClassに構造を実装する代わりに、MyClassからMyClassを継承できることに注意してください。 これにより、間接呼び出しを回避できます。

 @interface MyClass : NSObject { struct MyClassMap* lookupTable; } - (id)lookup:(int)i; @end and MyClass.mm: #import "MyClass.h" #include <map> struct MyClassMap : std::map<int, id> { }; @implementation MyClass - (id)init { self = [super init]; if (self) lookupTable = new MyClassMap; return self; } - (id)lookup:(int)i { MyClassMap::const_iterator found = lookupTable->find(i); return (found == lookupTable->end()) ? nil : found->second; } - (void)dealloc { delete lookupTable; lookupTable = NULL; [super dealloc]; } @end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、メンバーの数が増えると、多数の新規/削除のためにこれは実用的ではなくなります。

制限事項

純粋なC ++では、クラスを使用して実装を行うことができますが、Objective-Cでは先頭の宣言が正しい必要があるため、この場合は機能しません。 C ++の文献では、shared_ptr <>およびauto_ptr <>を使用してオブジェクトを自動的に削除するための推奨事項を見つけることができます。 Objective-Cヘッダーファイルでは、これも失敗します。 また、構造体へのポインターから逃れることはできません。これは、コンパイラーが構造体に割り当てるメモリ量を知る必要があるためです。



実装は閉じられているため、派生クラスのメンバーに直接アクセスすることはできません。 ただし、構造宣言をセミクローズヘッダーファイルに配置できます。ヘッダーファイルは、この直接アクセスが必要な子孫クラスにのみ含まれます。 このような子孫は、Objective-C ++で作成する必要があります。

最後の考え

それでも、ほとんどすべての場合、Objective-CにC ++を埋め込むには、Pimplのイディオムが最適な選択肢であると思います。 構造体に含まれるメンバーが1つだけの場合でも、不要な型変換がないため、間接性が補償されます。 構造自体はポインタではないため、パフォーマンスは失われません。 C ++でObjective-Cを有効にする必要がある場合、次の方法で同じことができます：ヘッダーファイルでクラスの実装の宣言の前に、オープンC ++インターフェイスを定義し、対応する.mmファイルにObjective-Cメンバーの定義を配置します。