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

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 2

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?" :-)