Question

When we create a directshow filter and register it, static variables/functions are shared in multiple instances of the same filter. I believe this also applies to other ActiveX controls. For instance if I try to use something like;

static int counter = 0;

void someFunction() {
    counter++;
    // trace result here
}

If I start another instance of the same filter, second instance doesn’t start from 0 but where first instance counter left. And then they start to increase the same counter asynchronously.

My question is, is there any smart way to block sharing between static variables for DirectShow filters? It may sound silly but if we register the same filter with different GUID (by recompiling the same project with a different GUID and file output), static variables are not shared anymore because they are two different filters, right? So, is there any way I can simulate this using the same filter but keeping the statics?

What am I trying to do is to use a library with many static usage in it. Getting rid of all the static variables/functions is very hard. the library i’m trying to use uses old standards like Ansi C and doesn’t have a real object oriented design. So, encapsulation is not very easy. Most of the functions are in the global space, not in classes. Please keep that in mind. If I leave the statics as they are, single instance of the filter works fine but other instances start getting messed up because of shared (static) variables.

Answer 1

It is not actually specific to DirectShow, the question is a typical one: should I use static variables in multiple instances of my class.

Smart answer: if you don’t want to use static variables – don’t. Every instance of your filter is a separate instance of a class. Use it’s member variables and don’t use globals.

What am I trying to do is to use a library with many static usage in
it. Getting rid of all the static variables/functions is very hard.

Put all your statics into one big class, e.g. “state” and have a separate instance of this “state” per filter. This is really preferred way.

Another solution is to move all statics into child DLL and load it out-of-process, so that each instance is hosted by a separate process. While technically this sovles your problem directly – that is, in a child process all statics remain static and in the same time each owner filter owns a separate copy, the knowledge required to implement out-of-process DLL and interprocess communication basically assumes you can manage to successfully implement the first “state” solution mentioned in the previous paragraph.