Dans quelles circonstances le C++ destructeurs ne va pas être appelé?

Question

Je sais que mon destructeurs sont appelés normal de se détendre de la pile et lorsque des exceptions sont levées, mais pas lors de la sortie() est appelée.

Existe-il d'autres cas où mon destructeurs ne sont pas va être appelé? Ce sujet de signaux SIGINT ou SIGSEGV? Je présume que pour SIGSEGV, ils ne sont pas appelés, mais pour SIGNINT ils sont, comment puis-je savoir lequel des signaux détendre la pile?

Existe-il d'autres circonstances où ils ne seront pas appelés?

Answer 1

Existe-il d'autres circonstances où ils[les destructeurs] ne sera pas appelé?

1. De longs sauts: celles-ci interfèrent avec le naturel de la pile processus de déroulement et conduisent souvent à un comportement indéfini en C++.
2. Prématuré sorties (vous l'a déjà signalé ces, mais il est intéressant de noter que de jeter alors que déjà le déroulement de pile en raison d'une exception levée conduit à un comportement indéfini et c'est pourquoi il ne faut jamais jeter de dtors)
3. Jetant d'un constructeur de ne pas invoquer le dtor pour une classe. C'est pourquoi, si vous allouer plusieurs blocs de mémoire gérés par plusieurs pointeurs (et pas des pointeurs intelligents) dans un ctor, vous avez besoin d'utiliser la fonction de niveau de blocs try ou éviter l'utilisation de la liste d'initialiseur et un bloc try/catch dans le ctor corps (ou, mieux encore, il suffit d'utiliser un pointeur intelligent comme scoped_ptr depuis tout membre initialisé avec succès jusqu'à présent dans un initialiseur liste sera détruit, même si la classe dtor ne sera pas appelé).
4. Comme l'a fait remarquer, à défaut de faire un dtor virtuel lorsqu'une classe est supprimée par l'intermédiaire d'une base de pointeur peut ne pas invoquer la sous-classe dtors (comportement indéfini).
5. À défaut d'appel correspondant de l'opérateur delete/delete[] pour un nouvel opérateur/[nouveau] appel (comportement indéfini - risquent de ne pas invoquer dtor).
6. À défaut d'appeler manuellement la dtor lors de l'utilisation du placement de nouvelles dotées d'un allocateur de mémoire dans le désallouer la section.
7. Utilisant des fonctions comme memcpy qui copie uniquement un bloc de mémoire à l'autre sans avoir à copier ctors. mem* fonctions sont mortelles en C++ comme ils le bulldozer sur les données privées d'une classe, d'écraser les vtables, etc. Le résultat est généralement un comportement indéfini.
8. L'instanciation de certains des pointeurs intelligents (auto_ptr) sur un type incomplète, voir cette discussion

Answer 2

Un signal par lui-même de ne pas influer sur l'exécution de la thread en cours et donc l'invocation de destructeurs, parce que c'est un autre contexte d'exécution avec sa propre pile, où vos objets n'existent pas. C'est comme une interruption: il est manipulé de l'extérieur de votre contexte d'exécution, et, si elle est traitée, la commande est retournée à votre programme.

Même avec le multithreading, C++ le langage ne connaît pas la notion de signaux. Ces deux sont complètement orthogonaux les uns aux autres et sont précisées par deux indépendants des normes. La façon dont ils interagissent est jusqu'à la mise en œuvre, tant qu'il ne casse pas l'une des normes.

Comme une note de côté, un autre cas est quand l'objet destructeur ne sera pas appelé, c'est quand son constructeur lance une exception. Des membres destructeurs s'appelle toujours, cependant.

Answer 3

Un autre cas, ils ne seront pas appelés, si vous utilisez le polymorphisme et n'ont pas fait de votre base destructeurs virtuels.

Answer 4

abort termine le programme sans l'exécuter destructeurs pour les objets de automatique ou statique de la durée de stockage Standard dit. Pour les autres situations, vous devriez lire la mise en œuvre des documents spécifiques.