Puis-je utiliser if (pointer) au lieu de if (pointer! = NULL)?

Est-il sûr de vérifier un pointeur pour ne pas être NULLen écrivant simplement if(pointer)ou dois-je utiliser if(pointer != NULL)?

Vous pouvez; le pointeur nul est implicitement converti en booléen faux tandis que les pointeurs non nuls sont convertis en vrai. De la norme C ++ 11, section sur les conversions booléennes:

Une prvalue d'arithmétique, une énumération sans portée, un pointeur ou un pointeur vers un type de membre peut être convertie en une prvalue de type bool. Une valeur zéro, une valeur de pointeur null ou une valeur de pointeur de membre nul est convertie en false; toute autre valeur est convertie en true . Une prvalue de type std::nullptr_t peut être convertie en une prvalue de type bool ; la valeur résultante est false .

Oui vous pourriez.

• Un pointeur nul est converti en faux implicitement
• un pointeur non nul est converti en vrai.

Cela fait partie de la conversion standard C ++, qui relève de la clause de conversion booléenne :

§ 4.12 Conversions booléennes

Une prvalue d'arithmétique, une énumération sans portée, un pointeur ou un pointeur vers un type de membre peut être convertie en une prvalue de type bool. Une valeur zéro, une valeur de pointeur null ou une valeur de pointeur de membre nul est convertie en false; toute autre valeur est convertie en vrai. Une prvalue de type std :: nullptr_t peut être convertie en une prvalue de type bool; la valeur résultante est fausse.

Oui, vous pouvez. En fait, je préfère l'utiliser if(pointer)car c'est plus simple à lire et à écrire une fois que vous vous y êtes habitué.

Notez également que C ++ 11 a introduit nullptrce qui est préféré à NULL.

La question a reçu une réponse, mais je voudrais ajouter mes points.

Je préférerai toujours if(pointer)au lieu if(pointer != NULL)et if(!pointer)au lieu de if(pointer == NULL):

• C'est simple, petit

• Moins de chances d'écrire un code bogué, supposons que si j'ai mal orthographié l'opérateur de vérification d'égalité ==avec =
if(pointer == NULL)peut être mal orthographié if(pointer = NULL)Donc je vais l'éviter, le mieux est juste if(pointer).
  _{(J'ai également suggéré une condition Yoda en une seule réponse , mais c'est une question différente)}

• De même pour while (node != NULL && node->data == key), j'écrirai simplement ce while (node && node->data == key)qui est plus évident pour moi (montre que l'utilisation de court-circuit).

• (peut être une raison stupide) Parce que NULL est une macro, si supposons que quelqu'un redéfinisse par erreur avec une autre valeur.

La vérification explicite de NULL pourrait fournir un indice au compilateur sur ce que vous essayez de faire, ce qui conduit à être moins sujet aux erreurs.

Oui, vous pouvez. La possibilité de comparer des valeurs à des zéros implicitement a été héritée de C et est présente dans toutes les versions de C ++. Vous pouvez également utiliser if (!pointer)pour vérifier les pointeurs pour NULL.

Les cas d'utilisation pertinents pour les pointeurs nuls sont

• Redirection vers quelque chose comme un nœud d'arbre plus profond, qui peut ne pas exister ou n'a pas encore été lié. C'est quelque chose que vous devriez toujours garder étroitement encapsulé dans une classe dédiée, donc la lisibilité ou la concision n'est pas un problème ici.

• Des lancers dynamiques. Le cast d'un pointeur de classe de base vers une classe dérivée particulière (quelque chose que vous devriez à nouveau essayer d'éviter, mais que vous pourriez parfois trouver nécessaire) réussit toujours, mais aboutit à un pointeur nul si la classe dérivée ne correspond pas. Une façon de vérifier cela est

  Derived* derived_ptr = dynamic_cast<Derived*>(base_ptr);
  if(derived_ptr != nullptr) { ... }

  (ou, de préférence, auto derived_ptr = ...). Maintenant, c'est mauvais, car cela laisse le pointeur dérivé (peut-être invalide, c'est-à-dire nul) en dehors de la ifportée du bloc de sécurité . Ce n'est pas nécessaire, car C ++ vous permet d'introduire des variables convertibles booléennes dans une if-condition :

  if(auto derived_ptr = dynamic_cast<Derived*>(base_ptr)) { ... }

  ce qui est non seulement plus court et sûr pour la portée, mais aussi beaucoup plus clair dans son intention: lorsque vous vérifiez null dans une condition if séparée, le lecteur se demande "ok, donc derived_ptrne doit pas être nul ici ... eh bien, pourquoi le ferait il est nul? " Alors que la version d' une ligne dit très clairement « si vous pouvez en toute sécurité jeté base_ptrà Derived*, puis l ' utiliser ... ».

  La même chose fonctionne aussi bien pour toute autre opération d'échec possible qui retourne un pointeur, même si IMO vous devriez généralement éviter ceci: il est préférable d'utiliser quelque chose comme boost::optionalle "conteneur" pour les résultats d'opérations éventuellement échouées, plutôt que des pointeurs.

Donc, si le cas d'utilisation principal des pointeurs nuls doit toujours être écrit dans une variante du style implicite-cast, je dirais qu'il est bon pour des raisons de cohérence de toujours utiliser ce style, c'est-à-dire que je recommanderais if(ptr)plus if(ptr!=nullptr).

J'ai bien peur de devoir terminer par une annonce: la if(auto bla = ...)syntaxe n'est en fait qu'une approximation un peu lourde de la vraie solution à de tels problèmes: la correspondance de motifs . Pourquoi voudriez-vous d'abord forcer une action (comme lancer un pointeur) et ensuite considérer qu'il pourrait y avoir un échec ... Je veux dire, c'est ridicule, n'est-ce pas? C'est comme si vous aviez de la nourriture et que vous vouliez faire de la soupe. Vous le donnez à votre assistant avec la tâche d'extraire le jus, s'il s'agit d'un légume mou. Vous ne le regardez pas d'abord. Lorsque vous avez une pomme de terre, vous la donnez toujours à votre assistant, mais il vous la claque au visage avec une note d'échec. Ah, programmation impérative!

Bien mieux: considérez tout de suite tous les cas que vous pourriez rencontrer. Alors agissez en conséquence. Haskell:

makeSoupOf :: Foodstuff -> Liquid
makeSoupOf p@(Potato{..}) = mash (boil p) <> water
makeSoupOf vegetable
 | isSoft vegetable  = squeeze vegetable <> salt
makeSoupOf stuff  = boil (throwIn (water<>salt) stuff)

Haskell a également des outils spéciaux pour les cas où il y a vraiment une sérieuse possibilité d'échec (ainsi que pour tout un tas d'autres choses): les monades. Mais ce n'est pas le lieu pour les expliquer.

^{⟨/publicité⟩}

Oui bien sûr! en fait, écrire if (pointer) est un moyen plus pratique d'écrire que if (pointer! = NULL) car: 1. il est facile à déboguer 2. facile à comprendre 3. si accidentellement, la valeur de NULL est définie, alors aussi le code ne plantera pas

Oui. En fait, vous devriez. Si vous vous demandez si cela crée une erreur de segmentation , ce n'est pas le cas.

Comme d'autres ont déjà bien répondu, ils sont tous deux interchangeables.

Néanmoins, il convient de mentionner qu'il pourrait y avoir un cas où vous voudrez peut-être utiliser l'instruction explicite, ie pointer != NULL .

Voir également https://stackoverflow.com/a/60891279/2463963

Oui, vous pouvez toujours le faire car la condition 'IF' s'évalue uniquement lorsque la condition à l'intérieur devient vraie. C n'a pas de type de retour booléen et renvoie donc une valeur non nulle lorsque la condition est vraie, tandis que renvoie 0 chaque fois que la condition dans 'IF' s'avère être fausse. La valeur non nulle renvoyée par défaut est 1. Ainsi, les deux manières d'écrire le code sont correctes alors que je préférerai toujours la seconde.

Je pense qu'en règle générale, si votre expression if peut être réécrite comme

const bool local_predicate = *if-expression*;
if (local_predicate) ...

tel qu'il ne provoque AUCUN AVERTISSEMENT, alors THAT doit être le style préféré pour l' expression if . (Je sais que je reçois des avertissements lorsque j'attribue un ancien C BOOL( #define BOOL int) à un C ++ bool, sans parler des pointeurs.)

"Est-ce sûr..?" est une question sur le standard du langage et le code généré.

"Est-ce une bonne pratique?" est une question sur la façon dont la déclaration est comprise par tout lecteur humain arbitraire de la déclaration. Si vous posez cette question, cela suggère que la version "sûre" est moins claire pour les futurs lecteurs et écrivains.