Creating multiple instances of global statics in C++?

Question

One of the libraries we are using for our product uses a singleton for access to it. I'm pretty sure it's implemented as a static instance (it isn't open source). This works well for a single document application, but our app may have more than one document loaded. I'm assuming access to the instance is written something like this:

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

In situations like this, is there some way to robustly create more than one instance? The only thing I can think of is to have more than process and use some type of IPC to tie it all together. I can't think of anything less hacky.

I have asked the vendor to implement some type of session token so I can have multiple concurrent instances, but they are big and we are small.

Cory

Edit:

• the machine is a Windows machine
• the global static is basically a big factory. I want a session token of some type so I can easily say "release all the resources from this session" (there's no way to re-initialize the global statics that I know of)

Rather than try some dodgy shenanigans to get what I want, I'm going to wrap the whole thing with my own class and add a session key to every getter. Internally I'll keep track of what has been allocated add my own release method to return resources. This is suboptimal for lots of reasons, but I can't think of a better idea.

Thanks to everybody for the great feedback.

Answer 1

I can't see a flaw in your reasoning unfortunately. The vendor has made a decision, and you are bound by it. He has decided on one instance per process, so if you want multiple instances you must have multiple processes with all that entails.

Of course if you assume that his decision to restrict is arbitrary, and that there is no good reason for it, you could attempt to hack around it. The way to start out on that path is to do some disassembling/assembly stepping in the debugger. If you can confirm that his instance factory works exactly as you have concluded above, you could no doubt hack together an alternative that allows creation of multiple instances.

But of course the huge risk with this approach is that every line of code in the vendor's codebase that relies on his decision to have a single instance is then a timebomb ready to blow up in your face. That code is invisible to you. Are you prepared to bet there are zero such lines ? I know what Clint Eastwood would say in a situation like this; "Do ya feel lucky punk, well do ya?" :-)

Answer 2

Even if you were able to solve this particular issue while having everything happen in-proc, I would be worried that this singleton issue is just the tip of the iceberg. The library obviously wasn't designed for your scenario.

Isolating each load of the DLL into its own process sounds right and non-hacky to me, though of course it could be expensive for you.

Answer 3

There are no elegant ways to have multiple instances of a singleton object in one program space -- but that is on purpose. In general, you only use a singleton in the case where it is undesirable to have multiple instances. If the vendor has implemented their product using a singleton, there may be good reasons for the choice.

Perhaps, if you describe your problem in more detail, there may be other approaches possible. It is hard to say, on the basis of the information supplied. What does the singleton object do? Why do you need multiple instances of it?

Answer 4

Except for the interprocess stuff you suggested, the best hack I can come up with is copying the dll to a new file and manually load the new dll and import all functions you use for each instance you create.

Hopefully this means the static variables won't conflict between the different instances since they are technically not in the same dll. However there are lots of bad things with this solution, such as all code in the dll being cloned for each version and you won't be able to use an import library, but have to load the dll and import all functions manually.

Answer 5

The only thing that I can think of is to sub-class it if you are lucky enough to have the singleton class defined like:

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

If you can subclass it and the subclass will have access to the constructor, then you can create an instanceable subclass like:

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

This might not be completely safe since the implementer may have made some nasty assumptions. But it is an idea or some approach that might have some chance of working. With any luck the vendor might be amenable to this option if you mention it... good luck.