Pila, Estática y Montón en C++

Lo siguiente, por supuesto, no es muy preciso. Tómalo con un grano de sal cuando lo leas:)

Bueno, las tres cosas a las que te refieres son la duración del almacenamiento automático, estático y dinámico, que tiene algo que ver con cuánto tiempo viven los objetos y cuándo comienzan a vivir.

Duración del almacenamiento automático

Utiliza la duración de almacenamiento automático para datos de corta duración y pequeños , que solo se necesitan localmente dentro de algunos bloque:

if(some condition) {
    int a[3]; // array a has automatic storage duration
    fill_it(a);
    print_it(a);
}

El tiempo de vida termina tan pronto como salimos del bloque, y comienza tan pronto como se define el objeto. Son el tipo más simple de duración de almacenamiento y son mucho más rápidos que la duración de almacenamiento dinámico en particular.

Duración del almacenamiento estático

Se utiliza la duración de almacenamiento estático para las variables libres, a las que cualquier código puede acceder todo el tiempo, si su ámbito permite dicho uso (ámbito de espacio de nombres), y para las variables locales que necesitan ampliar su vida útil a lo largo de la salida de su ámbito (ámbito local), y para las variables miembro que necesitan ser compartidas por todos los objetos de su clase (ámbito de clases). Su vida depende del alcance en el que se encuentren. Ellos pueden tener ámbito de espacio de nombres y ámbito local y el ámbito de la clase. Lo que es cierto acerca de ambos es que, una vez que comienza su vida, la vida termina en el final del programa. Aquí hay dos ejemplos:

// static storage duration. in global namespace scope
string globalA; 
int main() {
    foo();
    foo();
}

void foo() {
    // static storage duration. in local scope
    static string localA;
    localA += "ab"
    cout << localA;
}

El programa imprime ababab porque localA no es destruido al salir de su bloque. Se puede decir que los objetos que tienen ámbito local comienzan su vida cuando el control alcanza su definición. Para localA, sucede cuando se ingresa el cuerpo de la función. Para los objetos en el ámbito del espacio de nombres, la vida útil comienza en el inicio del programa. Lo mismo es cierto para los objetos estáticos de ámbito de clase:

class A {
    static string classScopeA;
};

string A::classScopeA;

A a, b; &a.classScopeA == &b.classScopeA == &A::classScopeA;

Como ves, classScopeA no está ligado a objetos particulares de su clase, sino a la clase misma. La dirección de los tres nombres anteriores es la misma, y todos denotan el mismo objeto. Hay una regla especial sobre cuándo y cómo se inicializan los objetos estáticos, pero no nos preocupemos por eso ahora. Eso se entiende por el término fiasco de orden de inicialización estática.

Duración dinámica del almacenamiento

La última duración de almacenamiento es dinámica. Lo utilizas si quieres que los objetos vivan en otra isla, y quieres poner punteros alrededor de esa referencia. También los usa si sus objetos son grandes, y si desea crear arrays de tamaño solo conocidos en tiempo de ejecución. Debido a esta flexibilidad, los objetos que tienen una duración de almacenamiento dinámica son complicados y lentos de administrar. Los objetos que tienen esa duración dinámica comienzan su vida útil cuando ocurre una invocación de operador nueva apropiada:

int main() {
    // the object that s points to has dynamic storage 
    // duration
    string *s = new string;
    // pass a pointer pointing to the object around. 
    // the object itself isn't touched
    foo(s);
    delete s;
}

void foo(string *s) {
    cout << s->size();
}

Su vida útil termina solo cuando llamas delete para ellos. Si te olvidas de eso, esos objetos nunca terminan su vida. Y los objetos de clase que definen un constructor declarado por el usuario no tendrán llamaron sus destructores. Los objetos que tienen una duración de almacenamiento dinámica requieren el manejo manual de su vida útil y el recurso de memoria asociado. Las bibliotecas existen para facilitar su uso. Recolección de basura explícita para objetos particulares se puede establecer usando un puntero inteligente:

int main() {
    shared_ptr<string> s(new string);
    foo(s);
}

void foo(shared_ptr<string> s) {
    cout << s->size();
}

No tiene que preocuparse por llamar a delete: El rpp compartido lo hace por usted, si el último puntero que hace referencia al objeto sale del ámbito. El ptr compartido en sí tiene automático duración del almacenamiento. Así que su vida útil se administra automáticamente, lo que le permite verificar si debe eliminar el objeto dinámico apuntado en su destructor. Para la referencia shared_ptr, consulte documentos de boost: http://www.boost.org/doc/libs/1_37_0/libs/smart_ptr/shared_ptr.htm

Se ha dicho elaboradamente, al igual que "la respuesta corta":

• Variable Estática (clase)
  lifetime = tiempo de ejecución del programa (1)
  visibilidad = determinada por modificadores de acceso (privado/protegido/público)

• Variable estática (ámbito global)
  lifetime = tiempo de ejecución del programa (1)
  visibility = la unidad de compilación en la que se crea una instancia(2)

• Variable de montón
  lifetime = definido por usted (nuevo en eliminar)
  visibilidad = definido por usted (a lo que le asigne el puntero)

• Variable de pila
  visibilidad = desde la declaración hasta la salida del ámbito
  lifetime = desde la declaración hasta que se sale del ámbito de la declaración

(1) más exactamente: desde la inicialización hasta la desinicialización de la unidad de compilación (es decir, el archivo C / C++). El orden de inicialización de las unidades de compilación no está definido por el estándar.

(2) Cuidado: si instanciar una variable estática en un encabezado, cada unidad de compilación obtiene su propia copia.

Estoy seguro de que uno de los pedantes encontrará una respuesta mejor en breve, pero la principal diferencia es la velocidad y el tamaño.

Pila

Dramáticamente más rápido para asignar. Se hace en O (1) ya que se asigna al configurar el marco de la pila, por lo que es esencialmente libre. El inconveniente es que si te quedas sin espacio en la pila, estás deshuesado. Puede ajustar el tamaño de la pila, pero IIRC tiene ~2MB para jugar. Además, tan pronto como salga de la función, todo en la pila se borrará. Así que puede ser problemático referirse a él más tarde. (Los punteros para apilar objetos asignados conducen a errores.)

Montón

Dramáticamente más lento para asignar. Pero tienes a GB con quien jugar y a quien apuntar.

Recolector de basura

El recolector de basura es un código que se ejecuta en segundo plano y libera memoria. Cuando asigna memoria en el montón, es muy fácil olvidarse de liberarla, lo que se conoce como fuga de memoria. Con el tiempo, la memoria que consume su aplicación crece y crece hasta se estrella. Tener un recolector de basura liberando periódicamente la memoria que ya no necesita ayuda a eliminar esta clase de errores. Por supuesto, esto tiene un precio, ya que el recolector de basura ralentiza las cosas.

¿Cuáles son los problemas de static y stack?

El problema con la asignación "estática" es que la asignación se hace en tiempo de compilación: no se puede usar para asignar un número variable de datos, cuyo número no se conoce hasta el tiempo de ejecución.

El problema con la asignación en la "pila" es que la asignación se destruye tan pronto como la subrutina que hace la asignación regresa.

Podría escribir una aplicación completa sin asignar variables en el montón?

Tal vez, pero no una aplicación grande, normal y no trivial (pero los llamados programas "incrustados" podrían escribirse sin el montón, utilizando un subconjunto de C++).

¿Qué recolector de basura hace ?

Sigue observando sus datos ("marcar y barrer") para detectar cuando su aplicación ya no hace referencia a ella. Esto es conveniente para la aplicación, porque la aplicación no necesita desasignar los datos ... pero el recolector de basura podría ser computacionalmente caro.

Los recolectores de basura no son una característica habitual de la programación en C++.

¿Qué podrías hacer manipulando la memoria por ti mismo que no podrías hacer usando este recolector de basura?

Aprenda los mecanismos de C++ para la desasignación de memoria determinista:

• 'estático': nunca desasignado
• 'stack': tan pronto como la variable "sale de alcance"
• 'heap': cuando se elimina el puntero (eliminado explícitamente por el aplicación, o suprimido implícitamente dentro de una u otra subrutina)

La asignación de memoria de pila (variables de función, variables locales) puede ser problemática cuando la pila es demasiado "profunda" y se desborda la memoria disponible para las asignaciones de pila. El heap es para objetos a los que se debe acceder desde varios subprocesos o durante todo el ciclo de vida del programa. Puede escribir un programa completo sin usar el montón.

Puede filtrar la memoria con bastante facilidad sin un recolector de basura, pero también puede dictar cuándo se liberan los objetos y la memoria. He corrido a problemas con Java cuando se ejecuta el GC y tengo un proceso en tiempo real, porque el GC es un hilo exclusivo (nada más se puede ejecutar). Por lo tanto, si el rendimiento es crítico y puede garantizar que no haya objetos filtrados, no usar un GC es muy útil. De lo contrario, solo te hace odiar la vida cuando tu aplicación consume memoria y tienes que rastrear la fuente de una fuga.

Qué pasa si su programa no sabe por adelantado cuánta memoria debe asignar (por lo tanto, no puede usar variables de pila). Digamos listas enlazadas, las listas pueden crecer sin saber por adelantado cuál es su tamaño. Por lo tanto, la asignación en un montón tiene sentido para una lista vinculada cuando no se sabe cuántos elementos se insertarían en ella.

Una ventaja de la CG en algunas situaciones es una molestia en otras; la confianza en la CG alienta a no pensar mucho en ella. En teoría, espera hasta el período "inactivo" o hasta que sea absolutamente necesario, cuando robará el ancho de banda y causará latencia de respuesta en su aplicación.

Pero no tienes que 'no pensar en ello.'Al igual que con todo lo demás en aplicaciones multiproceso, cuando puedes ceder, puedes ceder. Así, por ejemplo, en. Net, es posible solicitar un GC; haciendo esto, en lugar de menos frecuente más larga ejecución GC, puede tener más frecuente más corta ejecución GC, y difundir la latencia asociada con esta sobrecarga.

Pero esto derrota la atracción primaria de GC que parece ser "alentada a no tener que pensar mucho en ella porque es auto-mat-ic."

Si se expuso por primera vez a la programación antes de que GC se hiciera prevalente y se sintiera cómodo con malloc / free y new / delete, entonces podría incluso ser el caso de que encuentre GC un poco molesto y / o desconfía (como uno podría desconfiar de la 'optimización', que ha tenido una historia a cuadros.) Muchas aplicaciones toleran latencia aleatoria. Pero para las aplicaciones que no lo hacen, donde la latencia aleatoria es menos aceptable, una reacción común es evitar los entornos GC y moverse en la dirección de código puramente no administrado (o Dios no lo quiera, un arte moribundo, lenguaje ensamblador.)

Tuve un estudiante de verano aquí hace un tiempo, un interno, un chico inteligente, que fue destetado en GC; estaba tan adament sobre la superioridad de GC que incluso cuando programaba en C/C++ no administrado se negó a seguir el modelo malloc / free new / delete porque, cito, " no debería tener que hacer esto en un lenguaje de programación moderno."¿ Y sabes? Para aplicaciones pequeñas y de ejecución corta, de hecho puede salirse con la suya, pero no para aplicaciones de rendimiento de ejecución larga.

Stack es una memoria asignada por el compilador, cuando alguna vez compilamos el programa, por defecto el compilador asigna alguna memoria desde el sistema operativo (podemos cambiar la configuración desde la configuración del compilador en tu IDE) y el sistema operativo es el que te da la memoria, depende de mucha memoria disponible en el sistema y muchas otras cosas, y viniendo a stack memory es allocate cuando declaramos una variable copian (ref como formales) esas variables son empujadas a stack siguen algunas convenciones de nomenclatura por defecto su CDECL en Visual studios ejemplo: notación de infijo: c = a + b; el empuje de la pila se realiza de derecha a izquierda, b para apilar, operador, a para apilar y resultado de los i, e c para apilar. En notación pre fix: =+taxi Aquí todas las variables se empujan a la pila 1st (de derecha a izquierda)y luego se realiza la operación. Esta memoria asignada por el compilador es fija. Así que supongamos que se asigna 1MB de memoria a nuestra aplicación, digamos que las variables utilizan 700kb de memoria (todas las variables locales se envían a la pila a menos que se asignan dinámicamente) por lo que la memoria restante de 324 kb se asigna a heap. Y esta pila tiene menos tiempo de vida, cuando el alcance de la función termina estas pilas se borra.