En C++, los objetos globales y estáticos se inicializan antes de entrar en la función main(). Sin embargo, el estándar no garantiza el orden de inicialización de los objetos que se encuentran en diferentes unidades de traducción (archivos de compilación, translation units). Esto puede llevar a lo que se conoce como "static initialization order fiasco" — un error en el que un objeto global hace referencia a otro que aún no ha sido inicializado.
Para garantizar una correcta inicialización y evitar el problema, se utiliza el patrón "construct on first use": se declara una función que devuelve una referencia a un objeto estático local (se crea en la primera llamada de manera segura para hilos desde C++11).
// foo.h class Config { public: int value; }; Config& getConfig() { static Config config; config.value = 42; // ¡la inicialización está garantizada! return config; }
¿Qué ocurrirá si en dos archivos .cpp diferentes los objetos globales se crean entre sí?
Respuesta: El resultado es indefinido, puede haber una referencia a un objeto no inicializado. La solución es reemplazar la inicialización global directa por una perezosa a través de un objeto estático local dentro de la función (ver arriba).
Historia
-En un sistema CRM, dos módulos declararon registradores globales que se referían entre sí al inicializarse. En diferentes ensamblajes de la aplicación, el orden de inicialización cambiaba, apareciendo errores difíciles de detectar: caídas y registro en un puntero nulo.
Historia
-En un motor gráfico, un objeto contenedor global para recursos se refería a un administrador de recursos, que también era global. En Linux y Windows, los compiladores implementaban el orden de carga de manera diferente, resultando en desincronización y fallos distintos.
Historia
-Un desarrollador introdujo la inicialización global de configuraciones, y más tarde, un colega añadió otra variable global que dependía de las configuraciones. Esto funcionaba localmente y fallaba en CI, donde se realizaba una diferente composición de módulos.