4

製品に使用しているライブラリの 1 つは、アクセスにシングルトンを使用します。静的インスタンスとして実装されていると確信しています (オープンソースではありません)。これは単一のドキュメント アプリケーションではうまく機能しますが、アプリには複数のドキュメントが読み込まれている場合があります。インスタンスへのアクセスは次のように記述されていると想定しています。

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

このような状況で、複数のインスタンスを確実に作成する方法はありますか? 私が考えることができる唯一のことは、プロセス以上のものを持ち、何らかのタイプの IPC を使用してすべてを結び付けることです。これほどハックなことは考えられません。

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

コーリー

編集：

  • マシンは Windows マシンです
  • グローバルな静的は基本的に大きな工場です。「このセッションからすべてのリソースを解放する」と簡単に言うことができるように、何らかのタイプのセッション トークンが必要です (私が知っているグローバルな静的を再初期化する方法はありません)。

私が望むものを得るために危険な悪ふざけを試みるのではなく、すべてを独自のクラスでラップし、すべての getter にセッション キーを追加します。内部的には、割り当てられたものを追跡し、独自の release メソッドを追加してリソースを返します。これは多くの理由で最適ではありませんが、より良いアイデアは思いつきません。

素晴らしいフィードバックをありがとう。

4

5 に答える 5

5

この特定の問題をすべてインプロセスで解決できたとしても、このシングルトンの問題は氷山の一角にすぎないのではないかと心配しています。ライブラリは明らかにあなたのシナリオ用に設計されていません。

DLL の各ロードを独自のプロセスに分離することは、当然のことながらハックではないように思えますが、もちろんコストがかかる可能性もあります。

于 2009-05-30T00:19:29.203 に答える
4

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

もちろん、制限する彼の決定が恣意的であり、正当な理由がないと仮定する場合は、ハッキングを試みることができます。そのパスで開始する方法は、デバッガーで逆アセンブル/アセンブリ ステップを実行することです。彼のインスタンス ファクトリが上記の結論とまったく同じように機能することを確認できれば、複数のインスタンスを作成できる代替手段をハックすることは間違いありません。

しかしもちろん、このアプローチの大きなリスクは、ベンダーのコードベース内の単一のインスタンスを持つという彼の決定に依存するすべてのコード行が、あなたの目の前で爆発する準備ができている時限爆弾になることです。そのコードはあなたには見えません。そのような行がゼロであることに賭ける準備はできていますか? このような状況でクリント・イーストウッドが何を言うか知っています。「ラッキーパンクって感じですか？」:-)

于 2009-05-30T00:19:03.557 に答える
2

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

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

于 2009-05-30T00:27:47.220 に答える
1

あなたが提案したインタープロセスのものを除いて、私が思いつくことができる最善のハックは、dllを新しいファイルにコピーし、新しいdllを手動でロードし、作成する各インスタンスに使用するすべての関数をインポートすることです.

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

于 2009-05-30T00:28:00.293 に答える
1

私が考えることができる唯一のことは、幸運にもシングルトンクラスを次のように定義できる場合は、それをサブクラス化することです。

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

サブクラス化でき、サブクラスがコンストラクターにアクセスできる場合は、次のようなインスタンス化可能なサブクラスを作成できます。

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

実装者がいくつかの厄介な仮定を行った可能性があるため、これは完全に安全ではない可能性があります。しかし、それは機能する可能性があるアイデアまたは何らかのアプローチです。運が良ければ、ベンダーはこのオプションを受け入れてくれるかもしれません...幸運を祈ります。

于 2009-05-30T01:37:30.900 に答える