Sí, se traduce normalmente en una declaración implícita if
con una bandera booleana interna. Así, en la realización más básica de su declaración que habitualmente se traduce en algo así como
void go(int x) {
static int j;
static bool j_initialized;
if (!j_initialized) {
j = x;
j_initialized = true;
}
...
}
Además de eso, si su objeto estático tiene un destructor no trivial, el lenguaje tiene que obedecer a otra regla: este tipo de objetos estáticos tienen que ser destruido en el orden inverso de su construcción. Como la orden de construcción solo se conoce en tiempo de ejecución, la orden de destrucción también se define en el tiempo de ejecución. Entonces, cada vez que construyes un objeto estático local con un destructor no trivial, el programa tiene que registrarlo en algún tipo de contenedor lineal, que luego usará para destruir estos objetos en el orden correcto.
No hace falta decir que los detalles reales dependen de la implementación.
Vale la pena añadir que cuando se trata de objetos estáticos de tipos "primitivos" (como int
en su ejemplo) inicializados con constantes de tiempo de compilación, el compilador es libre para inicializar ese objeto en el arranque. Nunca notarás la diferencia. Sin embargo, si se toma un ejemplo más complicado con un objeto "no primitivos"
void go(int x) {
static std::string s = "Hello World!";
...
entonces el enfoque anterior con if
es lo que debe esperar encontrar en el código generado, incluso cuando el objeto se inicializa con una compilación -tiempo constante.
En su caso, el inicializador no se conoce en tiempo de compilación, lo que significa que el compilador tiene que retrasar la inicialización y usar ese implícito if
.
¿Cómo se implementa _por qué compilador_? –