この質問では、C++で記述された関数を直接呼び出す方法について2つの異なる答えを見ました。
次の質問の答えを見つけるために、SOタグ付き[perl][swig]のほぼすべての質問を閲覧しました。
私が考えているように、SWIGの使用は、この質問で尋ねられたように、他の用途ではより普遍的であり、Inline::CPPはperl固有です。しかし、perlの観点から、ここにいくつかの（何らかの）重要な違いがありますか？
SWIGを使ったことがないので、直接話すことはできません。しかし、私はInline::CPPにかなり精通しています。
コンパイルされてPerl内から呼び出し可能になるC++コードを作成したい場合は、Inline::CPPがこれを容易にします。C ++コードが変更されない限り、コンパイルは1回だけにする必要があります。モジュールをInline::CPPに基づいている場合、コードはモジュールのインストール時にコンパイルされるため、別のユーザーが最初のコンパイルの遅れを実際に目にすることはありません。これは、インストール時、テストフェーズの直前に発生します。
Inline :: CPPには、移植性の問題が100％含まれているわけではありません。ターゲットユーザーは、Perlのビルドに使用されるCコンパイラと同様のフレーバーのC ++コンパイラを持っている必要があり、C ++標準ライブラリは、Perlでバイナリ互換コードを生成するバージョンである必要があります。Inline :: CPPは、CPANテスターで約94％の成功率を示しています。そして、これらの最後の6％は、ほとんどの場合、使用するC++コンパイラとライブラリを正しく解読しないインストールプロセスの問題に要約されます。...そしてそれらのうち、それは通常ライブラリに帰着します。
モジュールの作成者として、95％がInline::CPPのインストールに問題がないことに気付いたとしましょう。ターゲットオーディエンスが同じカテゴリに分類されることがわかっている場合は、Inline::CPPに基づいてモジュールを作成するのは簡単です。基本的に、いくつかのディレクティブ（VERSIONとNAME）を追加し、Makefile.PLのExtUtils::MakeMaker呼び出しをInline::MakeMakerに交換する必要があります（ExtUtils :: MakeMakerが呼び出されます）。ディストリビューションを作成するときに、CONFIGURE_REQUIRESディレクティブでExtUtils::MakeMakerの現在のバージョンを指定することもできます。これにより、ユーザーがよりクリーンなインストールエクスペリエンスを利用できるようになります。
これで、一般消費用のモジュールを作成していて、ターゲットユーザーがInline :: CPPを使用できる94％の過半数に適合するかどうかわからない場合は、Inline::CPPの依存関係を削除する方がよいでしょう。とにかく依存関係の連鎖を最小限に抑えるためだけにこれを行うことをお勧めします。それはあなたのユーザーにとってより良いです。その場合は、Inline :: CPPで動作するようにコードを作成してから、InlineX::CPP2XSを使用して古いXSモジュールに変換します。これで、ユーザーは、最初にInline::CPPをプルするプロセスなしでインストールできるようになります。
C ++は大きな言語であり、Inline::CPPはその大きなサブセットを処理します。タイプマップファイルに注意して、どの種類のパラメーターを自動的に渡す（および変換する）ことができるか、および「ガッツとAPI」呼び出しを使用してどの種類のパラメーターをより適切に処理できるかを判断してください。私が使用することをお勧めしない機能の1つは、自動文字列変換です。これは、Unicodeに適さない変換を生成するためです。API呼び出しを介して文字列を明示的に処理することをお勧めします。
Inline ::CPPによって適切に処理されないC++の部分は、テンプレートメタプログラミングです。コードでテンプレートを自由に使用でき、STLを自由に使用できます。ただし、STLタイプのパラメータを単純に渡して、Inline::CPPがそれらを変換する方法を知っていることを期待することはできません。STLのものではなく、POD（基本データ型）を扱います。さらに、テンプレートベースの関数またはオブジェクトメソッドを作成する場合、C ++コンパイラは、Perlが関数を呼び出す予定のコンテキストを認識しないため、コンパイル時にテンプレートに適用するタイプを認識しません。したがって、Inline :: CPPに直接公開される関数とオブジェクトメソッドは、プレーンな関数またはメソッドである必要があります。テンプレート関数やクラスではありません。
実際には、これらの制限は、何を期待するかを知っている限り、対処するのは難しくありません。テンプレートクラスをInline::CPPに直接公開する場合は、テンプレートクラスを継承または構成するラッパークラスを作成しますが、Inline::CPPが機能する具体的な型を指定します。
Inline :: CPPは、既存のC++ライブラリの関数ラッパーを自動的に生成する場合にも役立ちます。ドキュメントには、その方法が説明されています。
Swigに対するInline::CPPの利点の1つは、perlguts、perlapi、およびperlcallの経験がすでにある場合は、すでに自宅にいるように感じることです。Swigを使用する場合は、最初にSwigの方法を学び、次にそれをPerlに適用する方法、そしておそらくCPANで配布可能な方法でそれを行う方法を理解する必要があります。
Inline :: CPPを使用するもう1つの利点は、Perlコミュニティではなじみのあるツールであるということです。Perl XS、Inline :: C、およびある程度Inline :: CPPを理解している人は、PerlでSwigを使用したことがある人よりもはるかに多くなります。XSは厄介なものになる可能性がありますが、PerlをSwigで使用するよりも移動量が多い道路です。
Inline :: CPPは、inline@perl.orgメーリングリストの一般的なトピックでもあります。私に加えて、Inline :: Cのメンテナと他のいくつかのInlineファミリーのメンテナがリストに頻繁にアクセスし、Inlineファミリのモジュールを使用するために手を必要とする人々を支援するために最善を尽くしています。
また、私のPerlMongersがInline:: CPPで話しているのは、それがどのように機能するかを調べるのに役立つかもしれません。さらに、Math :: Prime :: FastSieveは、モジュールをInline :: CPP（Inline :: CPP依存関係）に基づいた概念実証として機能します。さらに、現在のInlineメンテナであり、InlineX :: CPP2XSの作成者であるRob（sisyphus）は、実際にInlineX :: CPP2XSディストリビューションに、Math :: Prime :: FastSieveを取得し、彼を使用してプレーンXSコードに変換する例を含めました。 InlineX::CPP2XS。
おそらく、ExtUtils::XSppも見てみる必要があります。Inline::CPP や SWIG よりも少し多く宣言する必要があると思いますが、かなり強力です。