Création d'instances multiples de statics globaux en C ++?

Question

L'une des bibliothèques que nous utilisons pour notre produit utilise un singleton pour y accéder. Je suis sûr qu'il est mis en œuvre comme une instance statique (il est open source). Cela fonctionne bien pour une application unique de document, mais notre application peut avoir plus d'un document chargé. Je suppose que l'accès à l'instance est écrit quelque chose comme ceci:

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

Dans des situations comme celle-ci, est-il un moyen de créer plus robuste une instance? La seule chose que je peux penser est d'avoir plus de traiter et utiliser un certain type de IPC pour lier ensemble. Je ne peux pas penser à quoi que ce soit moins aki.

J'ai demandé au vendeur de mettre en œuvre un certain type de jeton de session pour que je puisse avoir plusieurs instances simultanées, mais ils sont grands et nous sommes petits.

Cory

Modifier:

• la machine est une machine Windows
• statique global est essentiellement une grande usine. Je veux un jeton de session d'un certain type, je peux facilement dire « libérer toutes les ressources de cette session » (il n'y a aucun moyen de ré-initialiser les statics globales que je connais)

Plutôt que d'essayer quelques manigances louches pour obtenir ce que je veux, je vais envelopper le tout avec ma propre classe et ajouter une clé de session à chaque getter. En interne, je vais garder une trace de ce qui a été alloué ajouter ma propre méthode de libération pour retourner les ressources. Ceci est suboptimale pour de nombreuses raisons, mais je ne peux pas penser à une meilleure idée.

Merci à tous pour les commentaires.

Answer 1

La seule chose que je peux penser est de sous-classe si vous êtes assez chanceux pour avoir la classe singleton définie comme:

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

Si vous pouvez sous-classe et la sous-classe aurez accès au constructeur, vous pouvez créer un instanceable sous-classe comme:

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

Cela pourrait ne pas être complètement sûr car le fait implémenteur peut avoir quelques hypothèses désagréables. Mais il est une idée ou une approche qui pourrait avoir une chance de travailler. Avec un peu de chance le vendeur peut se prêter à cette option si vous le dites ... bonne chance.

Answer 2

Même si vous étiez en mesure de résoudre ce problème particulier, tout en ayant tout se produit en proc, je serais inquiet que cette question singleton est que la pointe de l'iceberg. La bibliothèque n'a pas été conçu évidemment pour votre scénario.

Isoler chaque charge de la DLL dans son propre processus sonne juste et me non-aki, mais bien sûr, il pourrait être coûteux pour vous.

Answer 3

Je ne vois pas une faille dans votre raisonnement, malheureusement. Le vendeur a pris une décision, et vous êtes lié par. Il a décidé sur une instance par processus, donc si vous voulez plusieurs instances, vous devez avoir plusieurs processus avec tout ce que cela entraîne.

Bien sûr, si vous supposez que sa décision de restreindre est arbitraire, et qu'il n'y a pas de bonnes raisons pour cela, vous pourriez tenter de pirater autour d'elle. La façon de commencer sur cette voie est de faire quelques désassemblage / assemblage pas à pas dans le débogueur. Si vous pouvez confirmer que son usine d'instance fonctionne exactement comme vous avez conclu ci-dessus, vous pouvez pirater sans doute ensemble une alternative qui permet la création de plusieurs instances.

Mais bien sûr l'énorme risque avec cette approche est que chaque ligne de code dans le code de base du vendeur qui repose sur sa décision d'avoir une seule instance est alors une bombe à retardement prête à exploser au visage. Ce code est invisible pour vous. Êtes-vous prêt à parier qu'il ya zéro ces lignes? Je sais ce que Clint Eastwood dirait dans une telle situation; « Ne ya sentez le punk chanceux, ya bien faire? » : -)

Answer 4

Il n'y a pas de façons élégantes d'avoir plusieurs instances d'un objet singleton dans un espace de programme - mais est sur le but. En général, vous utilisez uniquement un singleton dans le cas où il est souhaitable d'avoir plusieurs instances. Si le fournisseur a mis en place leur produit en utilisant un singleton, il peut y avoir de bonnes raisons pour le choix.

Peut-être, si vous décrivez votre problème plus en détail, il peut y avoir d'autres approches possibles. Il est difficile de dire, sur la base des informations fournies. Qu'est-ce que l'objet singleton faire? Pourquoi avez-vous besoin de plusieurs instances de celui-ci?

Answer 5

À l'exception de la substance interprocessus vous le suggérez, le meilleur bidouille que je peux trouver est la copie du dll dans un nouveau fichier et charger manuellement la nouvelle dll et importer toutes les fonctions que vous utilisez pour chaque instance que vous créez.

Espérons que cela signifie que les variables statiques ne seront pas en conflit entre les différentes instances, car ils sont techniquement pas dans le même dll. Cependant, il y a beaucoup de mauvaises choses avec cette solution, comme tout le code dans le dll clonés pour chaque version et vous ne serez pas en mesure d'utiliser une bibliothèque d'importation, mais doivent charger les dll et importer toutes les fonctions manuellement.