C ++: Callbacks et événements minuterie du système pendant la cascade de destructor

Question

Supposons une conception OO où les objets s'appellent, et après un certain temps l'appel à des objets de rappel les objets initiant (appels et callbacks). Au cours de la fin normale du programme, alors que destructeurs sont appelés, est-il une sorte de promesse qu'aucun temporisateurs du système seront appelés, et aucun objet déclenche un rappel?

Answer 1

Il y a une bibliothèque assez impressionnant pour gérer ce genre d'appels, et bien sûr, il est un Boost.

Boost.Signals2 , avec des garanties de exactitude, même en application multithread:)

Notez en particulier l'utilisation de la classe boost::trackable, de sorte que la destruction des objets automatiquement les appels invalident avant qu'ils ne se produisent.

Note: Boost.Signals (son ancêtre) a à peu près les mêmes fonctionnalités, mais est thread-safe

Answer 2

Non, il n'y a pas de garantie.

Vous devez écrire votre code tels que les objets ne sont pas détruits jusqu'à ce que vous avez fini de les utiliser.

Answer 3

• weak_ptr de boost peut aider à éviter l'accès à des objets détruits de callbacks en général, donc probablement au cours de la fin. Lorsque vous utilisez ce, tous les objets qui ont besoin d'être rappelé, ont besoin d'un shared_ptr.
• minuteries les fonctions d'appel / callbacks sont généralement des bibliothèques haut de gamme, il dépend si elles prennent en charge une fonctionnalité stopAllTimers (). Si vous avez le contrôle sur la bibliothèque, il est sans doute pas trop difficile à mettre en œuvre, mais vous devez toujours savoir quand déclencher.

Answer 4

Non, il n'y a aucune promesse.

Il y a deux façons de gérer cela:

• une fonction de désenregistrement qu'un objet peut faire appel à la destruction, ce qui garantit pas callbacks sera appelée une fois elle se termine -. CancelAllCallbacks() ou similaire

• Avoir un mécanisme de référence faible, comme l'weak_ptr qui a déjà été mentionné, pour invoquer le rappel que si une référence forte a été obtenu avec succès.

En général, la première option est suffisante à moins que les callbacks peuvent être programmés ou invoqué de manière asynchrone - alors vous ne disposez pas d'une manière synchrone pour éviter un rappel qui est déjà prévu pour être appelé ou est en fait maintenant être appelé (ou quelques instructions à partir de maintenant) dans un thread différent.