As classes não derivadas de QObject deveriam “sempre” ser colocadas na pilha?

Question

Vindo do mundo Symbian, estou acostumado a usar o heap tanto quanto possível para evitar ficar sem espaço na pilha, especialmente ao lidar com descritores.As classes derivadas do CBase sempre foram alocadas dinamicamente no heap, pois caso contrário, suas variáveis-membro permaneceriam não inicializadas.A mesma convenção se aplica às classes derivadas de QObject?

No Qt parece ser comum colocar, por exemplo QString, na pilha.O conteúdo da string é colocado na pilha enquanto QString atua como um contêiner na pilha ou tudo é colocado na pilha?

Answer 1

Como sje397 disse:É idiomático colocar QString e contêineres na pilha, pois são compartilhados implicitamente.Seus internos (ponteiro "d" do idioma pimpl) são criados na pilha.Não faz sentido criar o próprio objeto na pilha também.Apenas causa problemas de gerenciamento de memória e você perde as propriedades pretendidas de cópia na gravação ao passar ponteiros para strings/contêineres.

QObjects por outro lado, você deseja criar no heap em quase todos os casos, caso contrário, eles seriam destruídos novamente imediatamente.Eles não podem ser copiados ou atribuídos (bem, pode-se aplicá-lo para as próprias subclasses, mas o QObject a semântica é quebrada então) e geralmente eles devem sobreviver ao corpo do método em que foram criados.A exceção é QDialog, que geralmente é criado na pilha, seguido por QDialog::exec, que é bloqueado até que a caixa de diálogo seja fechada.Mas mesmo isso é estritamente falado e inseguro, pois eventos externos (chamadas RPC, operações em segundo plano) podem fazer com que o diálogo seja excluído por seu pai (se o próprio pai for excluído) antes do retorno do exec.Então, criar a caixa de diálogo na pilha causará exclusão dupla ao desenrolar a pilha -> travamento.

Answer 2

QString e muitas outras classes Qt usam compartilhamento implícito de dados.Isso implica que a memória geralmente é alocada no heap.