Vérification de la nullité de l'objet

Question

Est-ce que cela a un sens de vérifier si ce est nulle ?

Disons que j'ai une classe avec une méthode ; à l'intérieur de cette méthode, je contrôle this == NULL et, si c'est le cas, renvoyer un code d'erreur.

Si ce est nulle, alors cela signifie que l'objet est supprimé. La méthode est-elle même capable de retourner quelque chose ?

Mise à jour : J'ai oublié de mentionner que la méthode peut être appelée depuis plusieurs threads et qu'elle peut entraîner la suppression de l'objet alors qu'un autre thread se trouve dans la méthode.

Answer 1

Est-il jamais utile de vérifier si this==null ? J'ai trouvé ceci en faisant une revue de code.

Dans le C++ standard, ce n'est pas le cas, car tout appel sur un pointeur nul est déjà un comportement non défini, donc tout code reposant sur de telles vérifications est non standard (il n'y a aucune garantie que la vérification sera même exécutée).

Notez que cela s'applique également aux fonctions non virtuelles.

Certaines implémentations permettent this==0 Cependant, et par conséquent, les bibliothèques écrites spécifiquement pour ces implémentations l'utiliseront parfois comme un hack. Un bon exemple d'une telle paire est VC++ et MFC - je ne me souviens pas du code exact, mais je me rappelle distinctement avoir vu if (this == NULL) vérifie dans le code source de MFC quelque part.

Il peut également être là comme une aide au débogage, parce qu'à un moment donné dans le passé, ce code a été frappé avec this==0 à cause d'une erreur de l'appelant, donc une vérification a été insérée pour attraper les futurs cas de ce genre. Une assertion aurait plus de sens pour de telles choses, cependant.

Si this == null, cela signifie que l'objet est supprimé.

Non, ça ne veut pas dire ça. Cela signifie qu'une méthode a été appelée sur un pointeur nul, ou sur une référence obtenue à partir d'un pointeur nul (bien que l'obtention d'une telle référence soit déjà U.B.). Cela n'a rien à voir avec delete et ne nécessite pas que des objets de ce type aient jamais existé.

Answer 2

Votre remarque sur les fils est inquiétante. Je suis presque sûr que vous avez une condition de course qui peut conduire à un crash. Si un thread supprime un objet et met à zéro le pointeur, un autre thread pourrait faire un appel par le biais de ce pointeur entre ces deux opérations, ce qui conduirait à this étant non nulle et également non valide, ce qui entraîne un crash. De même, si un thread appelle une méthode alors qu'un autre thread est en train de créer l'objet, vous pouvez également obtenir un plantage.

Réponse courte, vous devez vraiment utiliser un mutex ou quelque chose pour synchroniser l'accès à cette variable. Vous devez vous assurer que this est jamais nulle ou vous allez avoir des problèmes.

Answer 3

Pour info, j'ai utilisé des contrôles de débogage pour (this != NULL) dans les assertions avant qui ont aidé à attraper le code défectueux. Non pas que le code aurait nécessairement été trop loin sans un crash, mais sur les petits systèmes embarqués qui n'ont pas de protection mémoire, les assertions ont réellement aidé.

Sur les systèmes avec protection de la mémoire, le système d'exploitation rencontrera généralement une violation d'accès s'il est appelé avec une valeur NULL. this donc il y a moins de valeur dans l'affirmation de this != NULL . Cependant, voir le commentaire de Pavel pour savoir pourquoi il n'est pas nécessairement inutile sur des systèmes même protégés.

Answer 4

Votre méthode sera très probablement (cela peut varier selon les compilateurs) capable de s'exécuter et de retourner une valeur. Tant qu'elle n'accède à aucune variable d'instance. Si elle tente de le faire, elle se plantera.

Comme d'autres l'ont souligné, vous ne pouvez pas utiliser ce test pour voir si un objet a été supprimé. Même si vous le pouviez, cela ne fonctionnerait pas, car l'objet peut être supprimé par un autre thread juste après le test mais avant que vous n'exécutiez la ligne suivante après le test. Utilisez plutôt la synchronisation des threads.

Si this est nul il y a un bug dans votre programme, très probablement dans la conception de votre programme.

Answer 5

J'ajouterais également qu'il est généralement préférable d'éviter null ou NULL. Je pense que la norme est en train de changer encore une fois ici, mais pour l'instant, 0 est vraiment ce que vous voulez vérifier pour être absolument sûr d'obtenir ce que vous voulez.