Sont des signaux Qt automatiquement déconnecté lorsque l'un de la classe est supprimée

N'Qt supprimer automatiquement les connexions entre les objets , lorsque l'un des côté est supprimé ?

e.g connect (A .. , B ..) , lorsqu'Un (un pointeur) est supprimé , ou que B est supprimé , la connexion sera déconnecté ?

Est-il nécessaire d'utiliser déconnectez explicitement dans le destructeur ?

InformationsquelleAutor daisy | 2012-05-13
  1. 41

    Oui, le QObject::~QObject destructeur qui s'en occupe:

    Tous les signaux vers et à partir de l'objet sont automatiquement déconnectées, et de toute l'attente des événements publiés pour l'objet sont retirés de la file d'attente des événements.

    Cependant, il est souvent plus sûr d'utiliser deleteLater() plutôt que de supprimer une sous-classe QObject directement.

    Prenez soin de bien:

    Avertissement: la Suppression d'un QObject, tandis que les événements sont en attente de livraison peuvent provoquer un plantage. Vous ne devez pas supprimer le QObject directement si elle existe dans un autre thread que celui actuellement en cours d'exécution. Utilisation deleteLater() à la place, qui sera la cause de la boucle d'événement à supprimer l'objet après tout, en attendant les événements ont été livrés.

    • Notez également ceci: "Avertissement: la Suppression d'un QObject, tandis que les événements sont en attente de livraison peut provoquer une panne." Utiliser les deleteLater() si cette situation peut se produire.
    • attention également avec les lambdas (si vous utilisez) dans l'objet supprimé: ils ne sont PAS déconnectés... devinez comment je le sais 😉
    • Cela est vrai dans Qt5 ainsi.
    • depuis Qt 5.2 il y a une surcharge qui prend un objet de contexte. La connexion à la lambda va être déconnecté lorsque le contexte l'objet est supprimé.
    • Je suis toujours sur 5.1.1, mais je peux dire une chose: c'était nécessaire! 😉
    • Sont des connexions aussi déconnecté à partir d'objets de l'objet supprimé, si la de-les objets vivent dans d'autres threads?
    • Je crois qu'ils sont, mais je n'ai pas fait de Qt dans le passé quelques années, donc je suis rouillé. deleteLater certainement préférable et nécessaire si vous êtes à la suppression d'un objet appartenant à un autre thread (indiqué dans les docs).
    • probablement PAS. Je suis en mesure de détecter des collisions avec l'utilisation de Valgrind. Si un objet est marqué pour deleteLater() et avant, il est exécuté, si aucun nouveau signal est mis en file d'attente à partir d'un autre thread, qui conduit à un comportement indéterminé. Selon le système d'exploitation, il se bloque parfois à des endroits aléatoires. Difficile de suivre les bugs. 🙁
    • Je pense que vous pourriez obtenir le crash de quelque chose d'autre. Qt ne définir que le scénario dans le manuel. en attente de signaux et de deleteLater les deux sont des événements, qui sont effacés correctement si vous supprimez l'objet du thread approprié. Peut-être que votre deleteLater appels sont faits sur la mort de l'objet.
    • Je suis à l'aide de unique_ptr personnalisé deleter comme deleteLater, il est donc assuré que la suppression de l'objet est effectuée correctement. Il n'y a pas d'erreur avec valgrind soit (à savoir le double de libre). Qt dit que les signaux en attente avant de deleteLater() divertir. Mais imaginons un cas où le signal est émis sur un objet, après deleteLater() est marqué. Dans de tels cas, la deleteLater() se invoquée en premier, suivi par le signal. Il en résulte UB. De toute façon, je suis actuellement débogage d'une question, d'où la lib Qt est à l'origine de certains problèmes de mémoire de manière cohérente. Il y a quelques bugs dans Qt.
    • émis "sur" l'objet supprimé comme dans "émettent des Foo()" et de " Foo appartient à l'objet supprimé? Bien sûr, c'est un comportement indéfini. Sinon, l'émission sur un autre objet ne sera jamais appeler un slot d'un objet supprimé avec QueuedConnection, si l'objet a été deleteLater-ed et le deleteLater a déjà été traitée.
    • Bien sûr, si vous faites un DirectConnection, le moment de la fente est invoquée dans l'autre thread, deleteLater courses avec que du logement membre de l'accès et de comportement indéfini se pose. Supprimer peut alors se produire à tout moment dans l'objet propre thread.

    InformationsquelleAutor Mat