2016-06-14 8 views
0

プラグイン/モジュールAPIを提供するシングルスレッドアプリケーションを実装したいと思います。私のアプリケーションは、静的メソッドio_serviceを使用して、クラスメソッドでインスタンス化/初期化されています。それはある人によってシングルトンと呼ばれるかもしれません。これをプラグイン実装者が利用できるようにするのは良い考えですか?プラグイン間でboost :: asio :: io_serviceを共有する方法[modules]

boost::io_service& SomeClass::IOS() 
{ 
    static boost::io_service ios; 
    return ios; 
} 

まず私は、プラグインが唯一のファイル記述子を提供することを可能にすると、アプリケーションがstream_descriptorオブジェクトとしてそれらを包むと考えますが、これは、ブーストによって提供さio_object特定の機能を妨げます。これはプラグインの実装者にstatic io_serviceを提供し、io_objectインスタンスのみを使用するように制限した理由です。

+1

あなたのapiがboost asioヘッダーを含んでいれば、プラグインはすべて同じ#defines、debug level、ABIなどを使ってコンパイルされます。要するに、おそらくあなたのために働くでしょうし、他の誰かのために不可解に失敗します。 –

+1

この理由から、 'post'と' dispatch'(そしておそらくは鎖のラッパー?)を公開している公共の具体的なクラス(例えばDispatcher)にio_serviceをラップすることを検討することを強くお勧めします。 'std :: function '。 –

答えて

0

あなたのアーキテクチャがboost::asioに基づいている場合は、直接io_serviceをシングルトンとして公開することに問題はないと思います。

ABIに関する問題は、すべてのC++プラグインアーキテクチャーに共通しています。 で、boost::asioには該当しません。 io_service(リチャードの示唆)をラップすることはこの問題の解決策ではありませんが、asioの使用を隠す方法です。

はところで:私はあなたのプラグインがタスクをI/O asioを通じて、管理、およびメインアプリケーション派遣できるようにしたいと思いますので、あなたのラッパーが公開することは十分ではないでしょうプラグインの無用postdispatch( )、代わりにソケット、およびその他のI/Oメソッド。

+0

io_serviceオブジェクトをシグニチャとして提供するのではなく、io_objectインスタンスのファクトリメソッドが好ましいでしょう – DaTroop

+0

@DaTroopアプリケーションごとにio_serviceの一意のインスタンスを使用する必要があります。この場合、適切ではないファクトリがあります。メインアプリケーションはio_serviceインスタンスを作成し、それをプラグインに渡す必要があります。そして、この場合のIMHOには、io_service用のインタフェースを書く上で本当の価値はありません。 –

+0

私にとって懸念されるのは、io_serviceが公開されていることです。ですから、io_objectインスタンスの工場は、プラグイン開発者によるio_serviceの悪用を防ぎます。 – DaTroop

関連する問題