2009-05-29 7 views
4

私たちの製品に使用しているライブラリの1つは、アクセスにシングルトンを使用しています。私はそれが静的インスタンス(オープンソースではない)として実装されていると確信しています。これは単一のドキュメントアプリケーションでうまく動作しますが、アプリケーションに複数のドキュメントが読み込まれている可能性があります。このような状況ではC++でのグローバル統計の複数インスタンスの作成?

Instance* getInstance() { 
    static Instance* inst = new Instance(); 
    return inst; 
} 

、確実に つのインスタンスよりも多くを作成するためのいくつかの方法があります:?私はこのような何かを書かれているインスタンスへのアクセスを想定していますか私が考えることができるのは、IPCをすべて一緒に結びつけるために、何らかのタイプのIPCを処理して使用すること以上のものを持つことだけです。あまりハッキーなことは考えられない。

私はいくつかのタイプのセッショントークンを実装するようにベンダーに依頼しているので、複数の同時インスタンスを持つことができますが、それらは大きく、私たちは小さいです。

コーリー

編集:

  • マシンは、グローバルな静的は基本的に大きな工場であるWindowsマシン
  • です。私はそう、私は簡単に

(私が知っている世界的な静を再初期化する方法はありません)「このセッションからすべてのリソースを解放する」と言うのではなく、いくつかの危険なペテンを試すことができますいくつかのタイプのセッショントークンをしたいです私が望むものを得るために、私は自分のクラスですべてを包み込み、すべてのゲッターにセッションキーを追加するつもりです。内部的には、割り当てられたものを追跡して、リソースを返すために自分のリリースメソッドを追加します。これは多くの理由から最適ではありませんが、私は良いアイデアは考えられません。

皆様に感謝します。

+0

あなたはどのOSプラットフォームを使用していますか? – Skrymsli

+4

これがシングルトンが悪い理由です。単一のオブジェクトだけが存在することが本当に真剣でない限り、それはシングルトンであってはなりません。オブジェクトのインスタンスがいくつあるかを他の人に決定させます。 –

答えて

1

唯一のことは、あなたがシングルトンクラスを持つには十分に幸運のように定義されている場合は、それをサブクラス化することです実装者は、いくつかの厄介な仮定を作ったかもしれないので、これは完全に安全ではないかもしれません

class MyDocument: public Document { 
public: 
    MyDocument(): Document() { 
    } 
}; 

:コンストラクタは、その後、次のようなinstanceableサブクラスを作成することができます。しかし、それはアイデアや作業のチャンスがあるかもしれないいくつかのアプローチです。運が良ければベンダーはこのオプションに従うかもしれません。幸いです。

+0

私はあなたのサブクラスの考えが好きです。パブリック継承ではなく、グローバルスタティックをラップするためにコンポジションを使用し、セッショントークンサポートを追加するためにインターフェイスを変更します。応答していただきありがとうございます。 – criddell

4

残念なことに、あなたの推論に欠陥が見られることはありません。ベンダーは決定を下し、あなたはそれに拘束されます。彼はプロセスごとに1つのインスタンスを決定しました。したがって、複数のインスタンスが必要な場合は、すべてのプロセスが複数必要です。

もちろん、彼の制限の決定が恣意的であり、正当な理由がないと仮定すると、それをハックしようとする可能性があります。その道を始めるには、デバッガでいくつかの逆アセンブリ/アセンブリステッピングを行うことです。彼のインスタンスファクトリが上記のように正確に動作することを確認できれば、複数のインスタンスを作成できる代替案を一緒にハックすることは間違いありません。

もちろん、このアプローチの巨大なリスクは、ベンダーのコードベース内で、単一のインスタンスを持つことにしたがっているすべてのコード行が、あなたの顔に爆破する準備ができているということです。そのコードはあなたには見えません。あなたはそのような行がゼロであることを賭ける準備ができていますか?私はClint Eastwoodがこのような状況で何を言うのか知っています。 "ああ、幸運なパンクを感じますか?" :-)

5

すべてがprocで起こっている間にこの特定の問題を解決できたとしても、私はこのシングルトンの問題はちょうど氷山の一角に過ぎないと心配しています。ライブラリは明らかにあなたのシナリオ用に設計されていませんでした。

DLLの各負荷を独自のプロセスに分離することは、私には正しいとは言えませんが、もちろん高価になる可能性があります。

2

シングルトンオブジェクトの複数のインスタンスを1つのプログラム空間に配置するというエレガントな方法はありませんが、それは目的に沿ったものです。一般に、複数のインスタンスを持つことが望ましくない場合は、シングルトンのみを使用します。ベンダーがシングルトンを使用して製品を実装している場合、その選択には十分な理由があるかもしれません。

おそらく、問題をより詳細に記述すると、他にも可能な方法があるかもしれません。提供された情報に基づいて言うことは難しいです。シングルトンオブジェクトは何をしますか?なぜあなたはそれの複数のインスタンスが必要ですか?

1

提案したプロセス間の問題を除いて、私が思いつくところは、dllを新しいファイルにコピーし、新しいdllを手動で読み込んで、作成する各インスタンスごとにすべての関数をインポートすることです。

これは、技術的には同じDLLにないため、静的変数が異なるインスタンス間で競合しないことを意味します。しかし、このバージョンでは、dllのすべてのコードが複製され、インポートライブラリを使用することはできませんが、dllを読み込んですべての関数を手動でインポートするなど、このソリューションでは多くの悪いことがあります。

class Document { 
public: 
    static Document* getInstance() { 
     static Document inst; 
     return &inst; 
    } 
    virtual ~Document(); 
protected: 
    Document(); 
private: 
    struct Impl; 
    Impl *pImpl; 
}; 

あなたがそれをサブクラス化することができますし、サブクラスはへのアクセスを必要があります場合:私は考えることができる

関連する問題