Pregunta

Una de las bibliotecas que estamos utilizando para nuestro producto utiliza un producto único para el acceso a la misma. Estoy bastante seguro de que está implementado como una instancia estática (no es de código abierto). Esto funciona bien para una sola aplicación de documento, pero nuestra aplicación puede tener más de un documento cargado. Estoy asumiendo que el acceso a la instancia está escrito algo como esto:

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

En situaciones como ésta, ¿hay alguna manera de crear más robusta una instancia? Lo único que puedo pensar es tener más de procesar y utilizar algún tipo de IPC para atar todo junto. No puedo pensar en nada menos hacky.

He pedido al proveedor para implementar algún tipo de token de sesión para que pueda tener múltiples instancias concurrentes, pero son grandes y que son pequeñas.

Cory

Editar:

  • la máquina es una máquina de Windows
  • la estática global es básicamente una gran fábrica. Quiero un token de sesión de algún tipo por lo que puedo decir fácilmente "liberar todos los recursos de esta sesión" (no hay manera de volver a inicializar la estática globales, que yo sepa)

En lugar de tratar algunas travesuras poco fiables para conseguir lo que quiero, voy a envolver todo el asunto con mi propia clase y añadir una clave de sesión para cada captador. Internamente Voy a mantener un registro de lo que se ha asignado añadir mi propio método de liberación para devolver los recursos. Esto no es óptimo para un montón de razones, pero no puedo pensar en una mejor idea.

Gracias a todos por los comentarios.

¿Fue útil?

Solución

Lo único que se me ocurre es subclase si se tiene la suerte de tener la clase Singleton se define como:

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

Si puede subclase y la subclase tendrá acceso al constructor, a continuación, puede crear un instanceable subclase como:

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

Esto podría no ser completamente segura ya que el implementador puede haber hecho algunas suposiciones desagradables. Pero es una idea o algún método que podría tener alguna posibilidad de trabajar. Con un poco de suerte el vendedor podría ser susceptible de esta opción si mencionas ... buena suerte.

Otros consejos

Incluso si fueron capaces de resolver este asunto en particular al tiempo que todo suceda en proceso, yo estaría preocupado de que esta cuestión Singleton es sólo la punta del iceberg. La biblioteca, obviamente, no fue diseñado para su escenario.

El aislamiento de cada carga de la DLL en su propio proceso suena bien y no hacky para mí, aunque por supuesto que podría ser costoso para usted.

No puedo ver un defecto en su razonamiento por desgracia. El vendedor ha tomado una decisión, y que están obligados por ella. Él ha decidido sobre una instancia por el proceso, así que si quieres varias instancias debe tener varios procesos con todo lo que conlleva.

Por supuesto, si se asume que su decisión de restringir es arbitraria, y que no hay una buena razón para ello, se podría tratar de cortar a su alrededor. La manera de empezar a cabo en ese camino es hacer una intensificación de desmontaje / montaje en el depurador. Si puede confirmar que su fábrica ejemplo funciona exactamente como usted ha llegado a la conclusión anterior, podría sin duda hackear juntos una alternativa que permite la creación de varias instancias.

Pero por supuesto, el gran riesgo de este enfoque es que cada línea de código en el código base del proveedor que se apoya en su decisión de tener una única instancia es entonces una bomba de tiempo a punto de estallar en la cara. Ese código es invisible para el usuario. ¿Está dispuesto a apostar hay cero esas líneas? Sé lo Clint Eastwood diría en una situación como ésta; "¿Se sienten afortunados de punk, así hace el you?" : -)

No hay maneras elegante de tener varias instancias de un objeto único en un espacio de programa - pero eso es a propósito. En general, sólo se utiliza un producto único en el caso en que no es deseable tener múltiples instancias. Si el vendedor ha puesto en marcha su producto utilizando un producto único, puede haber buenas razones para la elección.

Tal vez, si usted describe su problema con más detalle, puede haber otros enfoques posibles. Es difícil de decir, sobre la base de la información suministrada. ¿Qué hace el objeto singleton? ¿Por qué necesita varias instancias de la misma?

A excepción de la materia entre procesos sugeriste, el mejor truco que puedo llegar a es copiar el archivo DLL en un nuevo archivo y manualmente cargar el nuevo archivo DLL e importar todas las funciones que utiliza para cada instancia se crea.

Esperamos que esto significa que las variables estáticas no entren en conflicto entre los diferentes casos, ya que técnicamente no están en la misma DLL. Sin embargo, hay un montón de cosas malas con esta solución, como todo el código en el archivo DLL de ser clonados para cada versión y usted no será capaz de utilizar una biblioteca de importación, sino que tienen que cargar el archivo DLL e importar todas las funciones de forma manual.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top