será?: ainda tem programadores por aí que mesmo conhecem os termos stack ou heap? Pensei que tinham todos sido idiotizados por Java, Delphi e a maioria das linguagens modernas...

--
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Entao quer dizer quem: Entao quer dizer quem programa em Java ou Delphi, Python, etc... nao sabe oq é isso?

Bom saber, assim eu apago estes termos da minha memoria. Mas calma la, apago da minha stack ou heap? =/

Uma sugestão pra vc, aprenda a escrever antes de escrever bobagens. ;)

Lapso de memória: Confesso que tinha me esquecido o que esses termos significavam.

Há muitos anos que tenho não preocupação de fazer matemática de ponteiros ou ter que desalocar memória não mais utilizada.

é: "Entao quer dizer quem programa em Java ou Delphi, Python, etc... nao sabe oq é isso?"

aparentemente, sim.

"Mas calma la, apago da minha stack ou heap? =/"

Se vai apagar manualmente, é do heap, da stack a coleta é automática quando do retorno da função que a alocou, lembra? ou foi deletado da memória? :D

"aprenda a escrever antes de escrever bobagens. ;)"

obrigado, mas não acho que preciso. Você, por outro lado, podia usar uns acentos aqui e ali...

--
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Exatamente. E, embora aqui: Exatamente. E, embora aqui estejamos nos referindo somente à esquemas de alocação de memória em compiladores, vale lembrar que stack e heap são estruturas de dados genéricas e úteis em muitas situações. Lamentavelmente, neguinho hoje joga tudo em XML ou Collections ou alguma outra solução pasteurizada, sobrecarregando a memória das maneiras mais estapafúrdias...

e ninguém implementa mais nada, dependendo do que os programadores da Sun ou M$ lhes prover...

--
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Ficou faltando uma coisa...: Amigos

Bom artigo, acho que poderia ter comentado sobre auto_ptr que permite você usar objetos alocados no heap sem se preocupar em deletá-los depois.

Nunca programei em QT, então não sei se são aplicáveis neste contexto (embora pelo que li tudo indica que sim).

A sintaxe é bem simples:
auto_ptr>um_tipo_de_class< ptr(new um_tipo_de_classe());

Exemplo:
auto_ptr>string< ptr(new string(”Teste”));

Quando a função em que o auto pointer está inserido termina, o destrutor do mesmo cuida de limpar a memória do objeto apontado.

Experimente usar auto_ptr e rodar um programa dentro do 'valgrind' e verá que não haverá leaks.


Atenciosamente


Adenilson

Auto ptr: Ola!

Obrigado pelos comentarios! A sua sugestao de falar sobre auto_ptr e' muito boa. Auto_ptr's serao abordados no post da semana que vem :)

Obrigado
[]'s

Rafael

E quem programa em python,: E quem programa em python, pearl, ruby, etc... implementam alguma coisa?

Tratar da questão sobre stack ou heap...: ... se torna mais necessária e séria quando estamos desenvolvendo sob plataforma com recursos limitadissimos, como plataformas para soluções embarcadas com limitações de memória e armazenamento "finitos".

Quando cito o termo "finito" não significa que o desktop tem recursos infinitos, mas é bem mais fácil amplia-los do que nos embarcados.

Sem contar que o hardware de mesa se tornou tão poderoso que desconsideramos o fato de que sua capacidade tem um limite.

No mais, para Java, PHP, Python e outras que estão em alto nível, essa questão do Heap e Stack é "quase" irrelevante.

Ah. Nemesis, um programa em Delphi pode ter a preocupação com Stack & Heap sim senhor, o desenvolvedor só não tem atualmente devido ao fato do poder "infinito" das máquinas atuais (conforme citei anteriomente).

--
Popolon Y2k
PlanetaMessenger.org
FreeBSD/OpenBSD/NetBSD/Linux - My dream team

Implementam regras de: Implementam regras de negócio do domínio da aplicação. Que é o que linguagens de alto nível se propõem, claro: libertar o programador de detalhes do hardware subjacente. E torná-lo mais idiotizado e barato para repor. são dois objetivos conflitantes...

--
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

quase: "um programa em Delphi pode ter a preocupação com Stack & Heap sim senhor, o desenvolvedor só não tem atualmente devido ao fato do poder "infinito" das máquinas atuais"

Na verdade, como desenvolvedor Delphi (lamentavelmente), posso dizer que não temos. Praticamente só se usam componentes visuais para tudo e esses componentes ficam uns dentro dos outros e a responsabilidade de criação e destruição desses objetos fica por conta do pai. Dessa forma, o programador Delphi praticamente só faz montar telas e no fim chamar algo como form := TForm.Create( pai ); daí todo o resto fica por conta do próprio framework do Delphi. No Delphi, na prática, não se usam registers ou mesmo instâncias de classes de usuário, só componentes visuais para tudo. é insano, é verdade...

Pra ser honesto, programando GTK+ em C também não há muito gerenciamento manual de memória para destruição de widgets: eles usam reference-counting internamente...

--
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Quase (com comentários) .....: ...pois como desenvolvedor Delphi (orgulhosamente), concordo que o framework faz tudo automaticamente quando os componentes visuais são criados pelo framework da aplicação, mas quando vc é o responsável por criar suas instâncias de objetos manualmente (form := TForm.Create( pPai );), aí vc é obrigado (ou não) a saber da existência de questões como stack e/ou heap.

Quanto a destruição de objetos, tudo depende do framework utilizado, no caso do Delphi, se eu criar um componente manualmente, certamente o Framework não vai destrui-lo "automagicamente" e teremos um memory-leak.

--
Popolon Y2k
PlanetaMessenger.org
FreeBSD/OpenBSD/NetBSD/Linux - My dream team

não: "quando vc é o responsável por criar suas instâncias de objetos manualmente (form := TForm.Create( pPai );), aí vc é obrigado (ou não) a saber da existência de questões como stack e/ou heap."

não, vc só precisa se ater às boas e óbvias regras de convivência: abriu/fechou, sujou/limpou. Delphi só usa stack para tipos simples/nativos e registers, todo o resto OO é heap. E a maioria dos delpheiros nem se dá conta de qualquer modo...

BTW, essas convenções delphi de nomenclatura são um pé-no-saco, né não? pPai?! papai!! :P

--
;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Foi o que eu disse...: ...vc precisa ficar atento e saber o que é heap e stack.

"não, vc só precisa se ater às boas e óbvias regras de convivência: abriu/fechou, sujou/limpou. Delphi só usa stack para tipos simples/nativos e registers, todo o resto OO é heap"

Quanto as nomenclaturas pé-no-saco, na verdade usei a notação hungara de Charles Simonyi (ex-Xerox e atual M$ ???), pois acredito que seja uma interessante forma de identificação dos tipos de variáveis para as linguagens tipadas como Java, C/C++, Delphi e outras do genero.

O pPai, não é "papai" e sim p(Pointer) Pai (o nome da variavel) ou seja Ponteiro para o Form pai.

:.P

http://en.wikipedia.org/wiki/Hungarian_notation

--
Popolon Y2k
PlanetaMessenger.org
FreeBSD/OpenBSD/NetBSD/Linux - My dream team