[ LOW-LEVEL ] Memória: Stack e Heap

Sabe o que é engraçado? Programadores que vão manipular a pilha no baixo nível sabem que elas não são bem pilhas. Eu sempre omito isso, mas é o contrário. Vai de cima para baixo, é uma pilha morcegando :D

A Stack é conhecida por sua alocação automática, já que, ela mesma faz alocação e também a desalocação

Eu posso ter dado a entender isso. Mas na verdade a alocação em si é fixa da pilha toda. Ela deixa você usar um espaço dela e volta atrás quando não precisa mais daquilo. De fato é automaticamente que isso acontece. Quando inicia um escopo que tem um frame um ponteiro (stack pointer) "sobe" (de verdade, desce, mas é mais fácil enxergar como subindo) na pilha, e quando não precisa mais esse ponteiro volta para o lugar original, marcando onde é o topo da pilha naquele momento (o tipo lógico, o físico é fixo - em tese também, mas naõ vamos complicar).

O primeiro código no exemplo entra na pulha se estiver em uma função. É raro usar for,a mas se for a alocação não é na pilha.

A liberação do espaço em cada frame é no fum da função. A desalocação da puilha como um todo é no fim do programa. Isso acontece em C e quase todas as outras linguagens. Alguém pdoe inventar alguma maluquice.

Após o térmido do programa a memória é sempre liberada pelo sistema operacional, não tem risco. Em tese se você sabe que o programa vai rodar por pouco tempo e aloca pouco dinamicamente, pode até nmão usar o free() que estará tudo bem. Mas pra que fazer isso? Até tem caso que faz sentio, mas não faça por preguiça, acostume-se fazer o mais certo.

O problema é que sem o free() enquanto executa vai acumulando e vai estourar a a RAM, vai ficar muito lento (vai para a memória virtual em disco (SSD)), até quebrar de vez em casos extremos.

O exemplo mostrado está ok, mas é óbvio que fazendo assim não tem como se enrolar, o problema que a alocação assim costuma ser na pilha mesmo, se usa a forma dinâmica onde aloca em um lugar e libera em outro, aí começa ficar difícil, por isso o GC é uma técnica mais fácil, apesar de conbrar um preço.

Saber essas coisas ajuda programar melhor qualquer coisa, mesm oque nunca use direrentamente. Desde que a pessoa estude do jeito certo, tem gente que não consegue fazer associações depois.

Ajudei? Era o meu desejo.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui).

Obrigado pelo crédito.

Ajudei? Era o meu desejo.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui).

Muito bom esse conteúdo, hoje em dia com linguagem que não usam tipagem de dados, ninguém tem noção desses escopos de memória, simplesmente vão e fazem. Eu venho do java e posso dizer que para se ter performance você tem que entender essas partes e até um fine tunning com flags pro garbage collector é um assunto extenso. Na minha opinião a evolução do Hardware, as linguagens começaram abstrair muito esse assunto, e dai surgiram a escalabilidade pra contornar esse tipo de problema. Acredito muito que se tivessemos melhores programadores desse nível, não precisariamos ter tanto de escalibidade etc. Da uma olhada em rust tbm, é uma filosofia legal mas também tem uns conceitos estranhos kkk. Obrigado por compartilhar, vou acompanhar.

Ótimo post!

Se não me engano a heap é acessível em todos os threads e tem escopo global. E ela pode estar tanto na ram quanto no hd/ssd.

Cara muito bacana a explicação!

Quero adicionar aqui como isso é um pouco diferente em rust. Em rust a desalocação ocorre quando, por exemplo, uma variável sai de escopo.

fn exemplo(x: i32) {
    // usa o x para qualquer coisa
}

fn main() {
    let num = 42;
    
    exemplo(num);
    
    println("exemplo = {}", num); // Erro!
}

O código acima na maioria das linguagens não teria problemas. Em rust, por conta de algumas regras no compilador, nem compila esse código pois a variavel 'num' foi entregada para a função 'exemplo' e isso faz com que essa função agora seja 'dona' da variável. Então assim que a função termina a variável foge de escopo e ela é automáticamente desalocada, por isso não é possível fazer o print depois.

Só isso já evita muitos erros que poderiam acontecer envolvendo alocação e acesso a memória, e acho rust bem bacana por se preocupar com essas coisas.