Pourquoi / Quand utiliser (!! p) au lieu de (p! = NULL)

Question

Dans le code suivant, quel est l'intérêt d'utiliser (!! p) au lieu de (p! = NULL) ?

AClass *p = getInstanceOfAClass();
if( !!p )
  // do something
else 
  // do something without having valid pointer

Answer 1

C'est une question de style, en fait, ils sont équivalents. Voir cette question très similaire pour en savoir plus.

La comparaison de l’OMI avec le pointeur null est plus claire.

Answer 2

C'est à peu près la même chose, bien que je considère le !! p comme un mauvais style et indique généralement un codeur essayant d'être intelligent.

Answer 3

Je pense que le commentaire original de GMan devrait être la réponse acceptée:

  

Je me demande ce qui ne va pas avec seulement si (p)

Le problème est le suivant: rien ne s'y trompe pas, et cette devrait être la méthode préférée. Tout d’abord, !! p est & # 8220; trop intelligent & # 8221 ;; C’est également tout à fait inutile et donc mauvais (remarque: nous parlons ici de pointeurs dans une instruction si , aussi le commentaire Anacrolix, bien qu’il soit généralement valide, ne le fait pas. ne pas appliquer ici!).

Il en va de même pour p! = NULL . Même si cela est possible, ce n’est tout simplement pas nécessaire. C’est plus de code, c’est du code complètement redondant et, partant, il aggrave le code. La chose la plus vraie que Jeff Atwood ait jamais dite est que & # 8220; le meilleur code est pas de code du tout. & # 8221; Évitez la syntaxe redondante. Tenez-vous-en au minimum (cela donne toujours le sens complet; si (p) est complet).

Enfin, if (p) est sans doute le moyen le plus idiomatique d’écrire cela en C ++. C ++ recule pour obtenir ce même comportement pour d'autres types du langage (par exemple, les flux de données), au prix de quelques bizarreries très étranges. La prochaine version de la norme introduit même une nouvelle syntaxe pour obtenir ce comportement dans les types définis par l'utilisateur.

Pour les pointeurs, nous obtenons la même chose gratuitement. Alors utilisez-le.

/ EDIT: À propos de la clarté: Sharptooth écrit que

  

La comparaison de l’OMI avec le pointeur null est plus claire.

Je prétends que cela est objectivement faux: si (p) est plus clair. Il n’existe aucune possibilité que cette déclaration veuille dire autre chose, ni dans ce contexte ni dans un autre, en C ++.

Answer 4

Pour autant que je sache, c’est un moyen plus rapide de le convertir en valeur booléenne. Il applique le! deux fois, cependant, alors que p! = NULL fait une comparaison. Donc, je suppose que l'avantage est simplement un code plus court, bien que plus crypté si vous ne savez pas ce que !! p est censé vouloir dire.

Answer 5

Ce sont les mêmes, mais je recommande d'utiliser

NULL != p

Il est plus lisible.

Answer 6

Il n'y a pas de différence dans l'exemple donné.

Cependant, l'hypothèse que cela s'applique à tous les cas est incorrecte. a = not not b n'est pas identique à a = b , en ce qui concerne les types entiers.

En C, 0 est faux. Tout sauf 0 est vrai. Mais pas 0 est 1 , et rien d’autre. En C ++, true renvoie 1 en tant qu'entier, non seulement pour assurer la compatibilité avec C, mais parce que 1 n'est pas 0 , et 1 est la valeur la plus utilisée pour indiquer la valeur true dans les types bool C, y compris les type officiel C bool et BOOL utilisés dans Win32.

Alors que pour l'exemple de code donné, !! p n'est pas nécessaire car le résultat est converti en bool afin d'évaluer la condition si . , cela n’exclut pas l’utilisation de !! pour convertir les valeurs booléennes en valeurs entières. Personnellement, dans cet exemple, pour maximiser la probabilité que les changements de type et la sémantique soient clairs, j'utiliserais NULL! = P ou p! = NULL pour bien préciser ce qui est signifiait.

Cette technique est connue sous le nom d'idiome à deux coups et fournie par ce gars quelques bonnes justifications .

Answer 7

NE PAS utiliser la double négation. Un argument simple est que, puisque le C ++ est un sous-ensemble anglais limité et que l’anglais n’a tout simplement pas une double négation, les anglophones auront beaucoup de difficulté à analyser ce qui se passe.