C++ 11 ofrece características como thread-safe initialization of static variables, y citando a esa pregunta vamos a decir por ejemplo:¿Alguna garantía de seguridad de subprocesos de C++ 11 se aplica a bibliotecas de subprocesos de terceros compiladas/vinculadas con C++ 11?
Logger& g_logger() {
static Logger lg;
return lg;
}
Así ostensiblemente esto es cierto independientemente de si un módulo compilado con un compilador de C++ 11 (?) incluía los encabezados de subprocesos o generaba subprocesos en su cuerpo. Se le ofrece la garantía incluso si se vinculó con otro módulo que usó hilos C++ 11 y llamó a la función.
Pero, ¿qué ocurre si su "otro módulo" que llama a este código no utiliza hilos C++ 11, sino algo así como Qt's QThread
. ¿Está entonces la inicialización atómica de la estática fuera del alcance de la capacidad de C++ 11 para hacer tal garantía? ¿O el simple hecho de que un módulo haya sido compilado con C++ 11 y luego vinculado con otro código de C++ 11 implica que usted obtendrá la garantía independientemente?
¿Alguien sabe una buena referencia donde se cubren problemas como este?
inicialización estática es una propiedad de idioma. No veo cómo esto puede verse afectado por una biblioteca específica. – pmr
@pmr Me parece un poco complicado porque, por ejemplo, la memoria de la estática anterior se asigna al comienzo del programa, pero el constructor ejecuta la primera vez que se llama a la función con el estático dentro de ella. Parecería requerir una omnisciencia sobre el modelo de subproceso subyacente para lograr esto, por lo que soy escéptico de que podría hacerlo bien si se mezcla QThread/C++ 11thread ... aunque hay una pequeña posibilidad de nuevos requisitos binarios que lo hagan funcionar . – HostileFork
@HostileFork: Siempre que ambos (C++ y qt) utilicen las mismas funciones de sistema operativo para enhebrar, no veo cómo algo podría salir mal. Además, no veo por qué ninguno de los dos debería usar las funciones de subprocesamiento del sistema operativo. – PlasmaHH