Al declarar variables en {} ámbito, ¿seguirán usando memoria después?

Question

en este ejemplo, a pesar de que nunca voy a usar el WNDCLASSEX las variables, x, y, CX, CY, van a seguir utilizando la memoria cuando estoy en el mensaje de bucle:

int WINAPI WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpArgs, int iCmdShow) 
    { 
    WNDCLASSEX wc; 
    ... 
    RegisterClassEx(&wc); 

    const int cx = 640; 
    const int cy = 480; 
    // center of the screen 
    int x = (GetSystemMetrics(SM_CXSCREEN) - cx)/2; 
    int y = (GetSystemMetrics(SM_CXSCREEN) - cy)/2; 

    CreateWindow(..., x, y, cx, cy, ...); 

    MSG msg; 

    while (GetMessage(&msg, NULL, 0, 0) > 0) 
    { 
     TranslateMessage(&msg); 
     DispatchMessage(&msg); 
    } 
    return 0; 
    } 

pero me pregunto , si los pongo en un ámbito, ¿seguirían usando memoria durante el ciclo de mensajes? p.ej.

int WINAPI WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpArgs, int iCmdShow) 
{ 
{ 
    WNDCLASSEX wc; 
    ... 
    RegisterClassEx(&wc); 

    const int cx = 640; 
    const int cy = 480; 
    // center of the screen 
    int x = (GetSystemMetrics(SM_CXSCREEN) - cx)/2; 
    int y = (GetSystemMetrics(SM_CXSCREEN) - cy)/2; 

    CreateWindow(..., x, y, cx, cy, ...); 
} 

MSG msg; 

while (GetMessage(&msg, NULL, 0, 0) > 0) 
{ 
    TranslateMessage(&msg); 
    DispatchMessage(&msg); 
} 
return 0; 
} 

o tal vez si los puse en dos funciones y los llamé en winmain p. Ej.

wnd_register(hInst); 
wnd_create(hInst); 

¿Qué les impediría usar la memoria?

Answer 1

El compilador tiene mucha libertad de acción para manejar locales sencillos, como lo ha hecho en sus ejemplos. Pueden vivir en la pila, solo pueden existir como valores inmediatos en el código de la máquina, o simplemente pueden vivir en registros. El espacio de pila generalmente se asigna al ingresar a una función. El compilador restará algún valor del puntero de pila para hacer espacio para todos los locales. Al regresar la función, el puntero de la pila vuelve a su valor original. Esto no suele hacerse al salir de diferentes bloques de alcance. La mayoría de los compiladores intentarán reutilizar agresivamente el espacio de pila tan pronto como las variables ya no se usen. En su ejemplo, sería perfectamente legal que x y msg tengan exactamente la misma dirección en la pila, ya que su uso no está superpuesto.

Mi respuesta a this question entra en más detalles sobre cómo se asignan las variables locales en la pila.

En sus ejemplos, las constantes, cx y cy, muy probablemente no tengan memoria que las respalde en el tiempo de ejecución, y solo serán valores inmediatos en el código generado. x e y muy probablemente vivirán en registros hasta que necesiten ser empujados a la pila para la llamada a CreateWindow. wc y msg casi definitivamente estarán en la pila.

No debe preocuparse por las micro-optimizaciones en este nivel: deje que el compilador asigne espacio para las variables locales como lo considere oportuno. Usted tiene una pila de 1 MB por defecto, la cantidad de datos consumidos por estas variables ni siquiera se registraría como ruido. Dedique su tiempo a preocuparse por problemas más interesantes en su lugar.

Answer 2

Oh dios no, cuatro enteros en la memoria mientras el programa se está ejecutando, ¡qué desperdicio!

1. Pruébelo, un simple mensaje que intenta imprimirlos debería ser suficiente (creo).
2. No importa.

Answer 3

Probablemente no, pero eso es un detalle de implementación. Sin embargo, se habrán destruido (se habrán realizado llamadas al destructor si hay alguna que hacer). La norma no especifica cuándo y cuándo el sistema recupera la memoria utilizada para el almacenamiento automático. La mayoría lo devuelve casi de inmediato afaik.

Answer 4

Las variables declaradas dentro de los {} saldrán del alcance y se perderán. De hecho, obtendrá un error de compilación si intenta usarlos fuera del bloque: 'x' no está declarado. Sin embargo, este es descuidado. Simplemente haga una función para este código, como dijo en su edición. Mantener su principal() tan pocas líneas como sea posible es una buena práctica de programación.

Answer 5

Bueno, no estoy seguro de si usan memoria o qué dicen las normas al respecto.

Lo que sí sé es que al final de un bloque de memoria {} se llamará al destructor y las variables serán inalcanzables. Esto podría significar que, si bien no se libera, al menos puede reutilizarse.

Ejemplo:

struct Foo { 
    Foo(void) { std::cout << "Hi!"; } 
    ~Foo(void) { std::cout << "Bye!"; } 
}; 

int main(int argc, char * argv[]) 
{ 
    { 
     Foo bar; // <- Prints Hi! 
    } // <- Prints Bye! 

    // Memory used by bar is now available. 
} 

Edit: Gracias Tomalak Geret'kal;)

Answer 6

Ellos no lo hará. Solo vivirán hasta el final de su bloqueo.

Answer 7

Un consejo mágico: Confíe en su compilador. Optimiza. Es inteligente Optimiza mejor que la mayoría de nosotros podría.

Si no está seguro, utilice un generador de perfiles o examine la salida del ensamblador del compilador después de las optimizaciones. Pero recuerde: las optimizaciones triviales es algo que debe hacer en su código , no, ya que no tiene sentido y solo daña la legibilidad de su código.

Algunas variables (especialmente las constantes) no usarán ninguna memoria en la pila porque se mapearán en los registros de la CPU o se incorporarán directamente en una instrucción de ensamblador.

Esto implica que los códigos:

func(123+456*198*value); 

y

int a = 123; 
int b = 56; 
int c = 400; 
int d = b+c; 
int e = d*198; 
e *= value; 
e += a; 
func(e); 

compile a exactamente lo mismo (si las variables nunca vuelvan a utilizarse).

En serio, no te molestes. Si desea optimizar, optimice desde el punto de vista algorítmico, no sintáctico.

Answer 8

Si los coloca en un ámbito anidado dentro de la función (su primera opción), cuando el control llega al final, las variables se vuelven inaccesibles (un error de compilación si los usa directamente o un comportamiento indefinido de tiempo de ejecución) si guarda un puntero a uno de ellos), se ejecutan sus destructores (si hay destructores), y la implementación puede reutilizar su espacio de almacenamiento dentro del marco de la pila. Pero los estándares no requieren para reutilizar el espacio.

Si divide su función en dos (su segunda opción) ... en términos de pelos estándar, ¡no hay diferencia! Cuando la función retorna, las variables se vuelven inaccesibles, se ejecutan sus destructores y la implementación puede reutilizar su espacio de almacenamiento, pero no es obligatorio. Y hay tienen implementaciones serias estado - aunque no de C/C++ - que no reciclar inmediatamente que la memoria: ver el más famoso el documento "Cheney on the M.T.A."

Sin embargo, todas las implementaciones de C/C++ que yo Ahora sé de do recicle la memoria asignada para las variables locales de una función cuando se devuelve una función. El reciclaje de memoria para variables de ámbito local anidado es mucho menos cierto. En cualquier caso, como varias otras personas han mencionado, no vale la pena preocuparse por unas pocas decenas de bytes de espacio de pila en este contexto.

Personalmente, dividiría su código en dos funciones solo porque de esa manera cada función hace una sola tarea. En general, es mejor para el mantenimiento a largo plazo.

Answer 9

Generalmente sí, si la variable reside en la pila, se tomará espacio para la pila durante todo el tiempo que dure la función adjunta. Los compiladores generalmente calculan la cantidad máxima de espacio que las variables de la función podrían ocupar y luego hacen que la función asigne todo a la vez cuando se ingresa por primera vez a la función. Sin embargo, los constructores y los destructores seguirán siendo llamados al entrar y salir de los ámbitos internos. El espacio para las variables en un ámbito puede volver a utilizarse para representar variables de un ámbito separado.