Au cas où les classes dérivées non QObject « toujours » être mis sur la pile?

Question

En venant du monde Symbian, je suis habitué à utiliser le tas autant que possible pour éviter de manquer d'espace de pile, en particulier lors de la manipulation des descripteurs. CBase classes dérivées ont toujours été attribuées de manière dynamique sur le tas, car s'ils ne sont pas, leurs variables membres resteraient non initialisée. La même convention appliquée aux classes dérivées QObject?

Dans Qt, il semble être commun à mettre, par exemple QString, sur la pile. Est-ce le contenu de la chaîne mise sur le tas tout en QString agit comme un conteneur sur la pile, ou tout est mis sur la pile?

Answer 1

Comme sje397 dit: Il est idiomatiques de mettre QString et des conteneurs sur la pile, car ils sont implicitement partagés. Leurs internes (idiome Pimpl pointeur « d ») sont créés sur le tas. Il n'y a pas de point dans la création de l'objet lui-même sur le tas, aussi. causes justes tracas de gestion de la mémoire et vous perdez les propriétés de copie en écriture destinés au passage des pointeurs vers des chaînes / conteneurs autour.

QObjects d'autre part vous voulez créer sur le tas dans presque tous les cas, faute de quoi ils seraient à nouveau détruits tout de suite. Ils ne peuvent pas être copiés ou cédés (bien, on peut l'appliquer pour les sous-classes propres, mais la sémantique de QObject sont brisés alors), et ils sont généralement censés survivre au corps de la méthode, ils sont créés dans. Exception est QDialog, qui est souvent créée sur la pile, suivi par QDialog::exec, qui bloque jusqu'à ce que la boîte de dialogue est fermée. Mais même cela est strictement parlé dangereux, comme les événements externes (appels RPC, les opérations d'arrière-plan) pourraient provoquer la boîte de dialogue à supprimer par son parent (si le parent lui-même est supprimé) avant le retour exec. Ensuite, la boîte de dialogue ayant créé sur la pile entraînera la suppression à double lors du déroulement de la pile -> crash.

Answer 2

QString, et beaucoup d'autres classes de Qt, utilisent partage de données implicite . Cela implique que la mémoire est généralement allouée sur le tas.