Re: When is the non-local static variable constructor run?
On Jan 27, 8:46 am, Daniel Kr?gler <daniel.krueg...@googlemail.com>
wrote:
Am 26.01.2012 20:49, schrieb paul 71:
[..]
Yes, this is a commonly used idiom of "registrars" for e.g.
deserialization object factories... Unfortunately it is very easy to
break on every implementation I have tried. If such non-locals as the
"ssc" from your example live in "static libraries" then the applied
linker optimization strategies are not able to see the side effects of
"sc" constructors. In your example, whenever a linker sees a usage of
"sc" (as in sc.SomeFunction()) the constructor for sc will be run. If
it does not, the symbol "sc" is just removed and the program behaves
as it would not be present.
As explained in my reply, this is easy to fix for static libraries in
practice. Just define a static variable in every *header* of the library
where the constructor calls a single time a function local static
variable. Here a sketch:
Right, I also mentioned in my reply that basically that (or something
similar) might be a fix... I just misspelled your name "Martin" vs.
"Daniel" for what I apologize :-) I have indeed used a similar pattern
in a large statically linked project successfully. It was a little bit
more involved, since depending on the compiler/linker implementation
and options I had to take care that these non-locals are really
**used** somewhere in the program. Have you tried to put your example
(userapi.cpp) into a static library, or did you just linked an object
to the executable? On both VC9 and VC10 if you do former, the static
symbols are always removed by the linker. If you do latter, then
depending on the optimization strategy size/speed/both and on some
other options ("keep/remove unused symbols") either you've got em or
not. We had to deploy for 4 different platforms with partially exotic
tool chains (which of course behaved completely odd) so that really
had to be foolproof.
My solution which enforced the initialization on every platform was
something along the way (out of memory, boilerplate code for Handles,
deleted/protected destructors and various NonInstatiable policies
omitted):
// IModule.h
struct IModule {
virtual void SetUp() = 0;
virtual void TearDown() = 0;
protected:
~IModule();
};
// IRegistar.h
struct IRegistrar {
virtual IModule* Create() = 0;
};
// IRegistry.h
struct IRegistry {
virtual void Register(IRegistrar *) = 0;
virtual void SetUp() = 0;
virtual void TearDown() = 0;
};
// Registry.h (singleton)
struct Registry : public IRegistry {
static IRegistry* GetRegistry();
};
// ModuleBase.h
template<class T>
class ModuleBase : IModule {
template< class U >
struct Registrar : public IRegistrar {
virtual IModule* Create()
{
return new U;
}
Registrar(IRegistry* pR) { pR->Register(this); }
};
static const Registrar<T> _;
};
template<class T>
const typename ModuleBase<T>::template Registrar<T> ModuleBase<T>::_ =
Registry::GetRegistry();
// Then, declare/define modules (your user_api.h):
// MyModule.h/.cpp
class Module : public ModuleBase<Module> {
virtual void SetUp();
virtual void TearDown();
};
#include <AllMyModules.h>
int main ()
{
Registry::GetRegistry()->SetUp();
Registry::GetRegistry()->TearDown();
}
.... and assure that the translation unit containing "main" includes
all your user Module.h files which was assured by a VS plug-in...
Somewhere in the program, there is an application class which call
Registry::SetUp of all modules which calls into IRegistrar::Create.
That convinced all linkers under all permutations of options that this
variable is really used (anything else would be odd of course).
However in the meantime I have switched to explicit loading of modules
with a COM-like treatment of initialization. For what it takes no non-
Windows support is required today, switching to real COM is also easy
now and I'm thinking of complete switch of platform for new stuff..
guess, which one I have in mind..
Cheers,
Paul
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]