Visite também: UnderLinux ·  VivaOLinux ·  LinuxSecurity ·  Dicas-L ·  NoticiasLinux ·  SoftwareLivre.org ·  [mais] ·  Efetividade ·  Linux in Brazil ·  Floripa  

Blog da Trolltech no Brasil analisa: Stack X Heap


“O post desta semana no blog da Trolltech no Brasil aborda um dilema que perturba muitos programadores: Usar stack ou heap?
O tema é tratado no contexto do Qt, entretanto também pode servir de exemplo para outras aplicações. Também gostaria de enfatizar que o blog está sob "nova direção", e que sugestões sobre futuros tópicos são bem-vindas.”


Enviado por Rafael Roquetto (rafael·roquettoΘtrolltech·com·br) - referência (blog.trolltech.com.br).

Comentários dos leitores

Os comentários abaixo são responsabilidade de seus autores e não são revisados ou aprovados pelo BR-Linux. Consulte os Termos de uso para informações adicionais. Esta notícia foi arquivada, não será possível incluir novos comentários.
Comentário de nemesis
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")

Comentário de Ricardo Cruz
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. ;)
Comentário de Bruno Laturner
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.
Comentário de nemesis
é: "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")

Comentário de nemesis
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")

Comentário de Adenilson Cavalcanti
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
Comentário de Rafael Roquetto
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
Comentário de xebe
E quem programa em python,: E quem programa em python, pearl, ruby, etc... implementam alguma coisa?

Comentário de popolony2k
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

Comentário de nemesis
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")

Comentário de nemesis
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")

Comentário de popolony2k
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

Comentário de nemesis
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")

Comentário de popolony2k
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

BR-Linux.org
Linux® levado a sério desde 1996. Notícias, dicas e tutoriais em bom português sobre Linux e Código Aberto. "A página sobre software livre mais procurada no Brasil", segundo a Revista Isto É.
Expediente
Sobre o BR-Linux
Enviar notícia ou release
Contato, Termos de uso
FAQ, Newsletter, RSS
Banners e selos
Anunciar no BR-Linux
BR-Linux apóia
LinuxSecurity, Tempo Real
Suporte Livre, Drupal
Verdade Absoluta
Pandemonium
Efetividade, Floripa.net
sites da comunidade
Ajuda
Moderação
Flames: não responda!
Publicar seu texto
Computador para Todos
Notícias pré-2004
Tutoriais, HCL pré-2004