C: Comparaison de la valeur NULL

Arguments religieux de côté:

  • Option1:

    if (pointer[i] == NULL) ...

  • Option2:

    if (!pointer[i]) ...

En C est option1 fonctionnellement équivalent à option2?

Le plus tard résoudre plus rapidement en raison de l'absence d'une comparaison ?

  • Est-il sûr de supposer que le "pointeur" est en fait un tableau de pointeurs? Elle pourrait rendre la question plus claire si vous retirez le "[i]".
  • Sudo, vous avez besoin pour se détendre. Vous êtes à hurler à jalf.com pour une réponse honnête. Le fait que vous êtes à même de demander: "ces ont des performances équivalentes" ou encore "ce sont les mêmes" démontre que vous avez besoin d'ouvrir votre esprit et ne pas assumer tout est une attaque.
InformationsquelleAutor Ande TURNER | 2009-08-16
  1. 17

    J'aime bien le deuxième, d'autres personnes comme la première.

    En fait, je préfère un troisième à la première:

    if (NULL == ptr) {
   ...
}

    Parce que je:

    • ne pourrez pas manquer et il suffit de taper un "="
    • de ne pas manquer l' "== NULL" et de l'erreur pour le contraire si la condition est long (plusieurs lignes)

    Fonctionnellement, ils sont équivalents.

    Même si un NULL pointeur n'est pas "0" (zéro tous les bits), if (!ptr) compare avec la NULL pointeur.

    Le suivant est incorrect. Il est toujours là parce qu'il y a de nombreux commentaires se référant à elle:
    Ne comparez pas un pointeur avec littérale zéro, cependant. Il travaillera presque partout, mais est un comportement indéfini IIRC.

    • Je n'aime pas la lisibilité de cette méthode. En java, il est possible d'éviter une NullPointerException en utilisant si ("bonjour".equals(obj.getAttr())) mais dans ce cas, vous n'avez rien en faveur de la diminution de la lisibilité...
    • "Ne comparez pas un pointeur avec littérale zéro, cependant. Il travaillera presque partout, mais est un comportement indéfini autant que je me souvienne." <- Non, c'est faux. Ce qui vous fait dire que c'est un comportement indéfini?
    • Thomas, voir c-faq.com/null/ptrtest.html. Il est parfaitement sûr pour comparer un pointeur vers le littéral 0.
    • Il peut en effet être quelque chose de valable à (void *)0 sur certaines architectures.
    • Mais, la valeur NULL est #défini à 0. Donc, si vous êtes en comparant les valeurs NULL, vous comparant à 0, aussi loin que le compilateur est concerné, parce que le compilateur traite pas ce type, mais le préprocesseur est de sortie, et le préprocesseur à remplacer NULL par 0. Donc, le fait qu'il peut y avoir quelque chose de valable à (void *) 0 n'est pas pertinent. NULLE sera remplacée par 0 avant le compilateur voit.
    • vous êtes sanglante de mal. Vous confondez la valeur de pointeur null et le pointeur null constante. La valeur NULL est toujours valide lorsqu'elle est définie sur 0. Ils définissent comme 0xFFFF bien sûr, n'est jamais valide. La valeur NULL est un pointeur null constante. Comme une exception (void*)0 est de trop, en C. Lorsqu'ils sont convertis en un type pointeur, il devient une valeur de pointeur null. C'est quand il devient un pointeur pointant vers une adresse pas égale à 0x0. Mais cela n'a rien à voir avec la comparaison d'un pointeur à 0. Ce n'est pas comparable à l'adresse 0. Un entier n'est pas une adresse.
    • à partir du standard C99 6.3.2.3: "Une constante entière expression avec la valeur 0, ou une expression en fonte de type void *, est appelé un pointeur null constante.55) Si un pointeur null constante, est converti en un type pointeur le pointeur résultant, appelé un pointeur null, c'est la garantie de comparer l'inégalité à un pointeur sur un objet ou une fonction." Qui dit en gros "0 utilisé dans un pointeur de contexte est NULL".
    • Aussi à partir de c++ standard 4.10: (italiques ajoutés) "Un pointeur null constante est une partie intégrante expression constante (5.19) rvalue de type entier qui prend la valeur zéro. Un pointeur null constante peut être converti en un type pointeur; le résultat est la valeur de pointeur null de ce type et se distingue de tous les autres de la valeur de pointeur vers l'objet ou le pointeur de fonction type."
    • Woah, vous savez que le point où vous êtes si calme de commencer à rêver, mais vous êtes encore éveillé, et d'une certaine façon de comprendre le monde de rêve de sens dans le monde éveillé? Je pense que j'ai été il y la nuit dernière. Désolé à tous.
    • Contrairement à C++, en C, NULL n'est pas 0 mais plutôt (void*) 0 - je ne sais pas, si cela fait une réelle différence.

    InformationsquelleAutor Thomas
  2. 33

    Je préfère l'explicite style (première version). Il est clair qu'il y a un pointeur impliquées et non un entier ou d'autre chose, mais c'est juste une question de style.

    À partir d'un point de vue des performances, il devrait pas faire de différence.

    InformationsquelleAutor Laserallan
  3. 31

    Équivalent. Il le dit dans la langue standard. Et les gens ont le damndest préférences religieuses!

    • si le mot être damnedest?
    InformationsquelleAutor Norman Ramsey
  4. 19

    Il est souvent utile de supposer que les rédacteurs du compilateur ont au moins un minimum d'intelligence. Votre compilateur est pas écrit par subi une commotion canetons. Il est écrit par des êtres humains, avec des années d'expérience de la programmation, et les années passées à étudier la théorie des compilateurs. Cela ne signifie pas que votre compilateur est parfait, et toujours connaît le mieux, mais il ne dire qu'il est parfaitement capable de gérer trivial optimisation automatique.

    Si les deux formes sont équivalentes, alors pourquoi ne pas le compilateur juste traduire l'une dans l'autre pour assurer les deux sont tout aussi efficaces?

    Si if (pointer[i] == NULL) a été plus lent que if (!pointer[i]), ne serait pas le compilateur, il suffit de changer dans le second, forme plus efficace?

    Donc pas, en supposant qu'ils sont équivalents, ils sont tout aussi efficaces.

    Comme pour la première partie de la question, oui, ils sont équivalents. La langue standard en fait l'indique explicitement quelque part, un pointeur prend la valeur true si elle est non NULLE, et false si elle est NULLE, de sorte que les deux sont exactement identiques.

    • Je pense qu'il ne fait, en fait. Je suis désolé si vous vous sentez offensé par elle. Je ne suis pas en attaquant la personne, tout en soulignant que cela, si vous arrêtez et pensez à ce sujet, être complètement et totalement évident. Si deux trivial construction du langage pour dire la même chose, alors ils seront compilés de la même façon. Si vous voulez parler de la condescendance, comment êtes-vous mieux? Vous êtes en supposant que vous, un débutant, est, dans environ 30 secondes, capable d'effectuer de meilleures optimisations que le très expérimenté les développeurs qui ont écrit de votre compilateur. Qui semble assez rude pour moi aussi. 😉
    • Si vous n'avez jamais eu à utiliser un compilateur écrit par subi une commotion ivre canetons, vous ne pouvez pas avoir été d'un logiciel d'écriture pour longtemps 😉 Heureusement, cependant, la sélection naturelle a vendu la plupart de ces histoires d'horreur - mais je m'attends à un peu sont encore là... le Plus important: compilateur écrivains ne sont pas des dieux, ils sont faillibles comme le reste d'entre nous, et le buggy code obtenez toujours écrit. Exemple: j'ai récemment eu affaire avec un compilateur c++/rtl où la mesure de la longueur d'un const string invoquer le constructeur de copie à chaque fois...
    InformationsquelleAutor jalf
  5. 9

    Presque certainement aucune différence dans les performances. Je préfère le style implicite de la seconde, si.

    InformationsquelleAutor Barry Kelly
  6. 3

    NULL doit être déclaré dans l'un des fichiers d'en-tête standard en tant que tel:

    #define NULL ((void*)0)

    Donc de toute façon, vous comparez par rapport à zéro, et le compilateur d'optimiser à la fois la même façon. Chaque processeur a une certaine "optimisation" ou de l'opcode pour comparer avec zéro.

    • En fait, pour elle C est #define NULL (void *)0.
    • Merde, j'ai eu mon C/C++ les valeurs Null en arrière. Je vais le mettre à jour, merci pour cette remarque.
    • C ne précise pas qui est NULL ((void*)0), il existe des plates-formes où il n'est pas.
    • Généralement il est ((void*)0), si. C'est sûr qu'il est sur Windows et Linux, et c'est plus qu'une hypothèse juste que l'OP est l'aide de l'un de ceux-ci. Il ne serait probablement pas demandé si il était à l'aide d'une plate-forme différente.
    • C permet NULL être définie comme 0.
    InformationsquelleAutor Mark Rushakoff
  7. 1

    Début de l'optimisation est mauvais. Micro optimisation est également mauvais, sauf si vous essayez de serrer chaque dernier peu de Hz à partir de votre CPU, il n'y a aucun point à elle de le faire. Comme les gens l'ont déjà montré, le compilateur d'optimiser le plus de votre code à l'écart de toute façon.

    De son mieux pour rendre votre code plus concis et lisible que possible. Si c'est plus lisible

    if (!ptr)

    que ce

    if (NULL==ptr)

    ensuite de l'utiliser. Tant que tout le monde qui va lire votre code est d'accord.

    Personnellement, j'utilise le entièrement défini la valeur (NULL==ptr) il est évident que je vérifie pour. Peut être plus long à taper, mais je peux facilement lire. Je pense à la !ptr serait facile de manquer ! si la lecture rapidement.

    • Non, au début de l'optimisation est mauvais surtout si vous essayez de serrer chaque dernier hz à partir de votre CPU.
    • "Micro-optimisation est également mauvais, sauf si vous essayez" Il y, qui fixe
    InformationsquelleAutor shimpossible
  8. 0

    Cela dépend vraiment sur le compilateur. Je serais surpris si la plupart des modernes, les compilateurs C ne pas générer pratiquement identiques code pour le scénario que vous décrivez.

    Obtenir votre compilateur pour générer une assemblée d'inscription pour chacun de ces scénarios et vous pouvez répondre à votre propre question (pour votre compilateur :)).

    Et même si ils sont différents, la différence de performances sera probablement pas pertinente dans des applications pratiques.

    InformationsquelleAutor
  9. 0

    Tour sur l'optimisation du compilateur et ils sont fondamentalement les mêmes

    testé sur gcc 4.3.3

    int main (int argc, char** argv) {
   char c = getchar();
   int x = (c == 'x');
   if(x == NULL)
      putchar('y');
   return 0;
}

    vs

    int main (int argc, char** argv) {
   char c = getchar();
   int x = (c == 'x');
   if(!x)
      putchar('y');
   return 0;
}


gcc -O -o test1 test1.c
gcc -O -o test2 test2.c


diff test1 test2

    produit aucune sortie 🙂

    • Aussi, en passant gcc -O0 pour aucun des optimisations en effet, les résultats dans les différents fichiers binaires.
    • Pourquoi les gens jusqu'à droit de vote de cette réponse? La question est de savoir sur les tests de pointeurs, alors que cet exemple, les tests d'un entier. Il n'est pas judicieux de tester un entier contre NULL; en fait, je soupçonne que vous obtenez un avertissement du compilateur si la valeur est NULL a été correctement définies et mises en garde ont été activés.
    InformationsquelleAutor Charles Ma
  10. -2

    J'ai fait un assemblage de vidage, et trouvé la différence entre les deux versions:


    @@ -11,8 +11,7 @@
    pushl %ecx
    subl $20, %esp
    movzbl -9(%ebp), %eax
    - movsbl %al,%eax
    - testl %eax, %eax
    + testb %al, %al

    Il ressemble à ce dernier génère une instruction et le premier génère deux, mais c'est assez peu scientifique.

    C'est gcc, pas d'optimisations:

    test1.c:

    #include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{ 
  char *pointer[5];

if(pointer[0] == NULL) {
  exit(1);
}

exit(0);

}

    test2.c: Changement pointer[0] == NULL à !pointer[0]

    gcc-s test1.c, gcc-s test2.c, diff -u test1.s test2.s

    • Quel était votre niveau d'optimisation, et quelle a été votre compilateur?
    • Et pourquoi êtes-vous en comparant char à NULL? La question était sur les pointeurs. (Peut-être que je suis en train de lire le démontage, le mal, n'hésitez pas à me frapper si c'est ainsi.)
    • Heureux de le voir, j'ai bien lu. 🙂 Activer les optimisations, le code sera probablement de même dans les deux tests.
    • J'ai changé le code pour un tableau de pointeurs, mais le résultat final est toujours le même.
    • En outre, en mettant -O3 dans ma ligne de compilation ne change pas le résultat (gcc 4.3). Non pas qu'il ne peut pas être optimisé en dehors, bien sûr.
    • Stratch que - optiziming à -O3, en effet, prendre la sortie le même.
    • Non seulement il fait de la sortie de même, en utilisant -O2 résultats dans un simple appel à exit(1), la comparaison est optimisé complètement. Notez aussi que votre extrait de caractéristiques de comportement indéfini (l'accès à un objet non initialisé).
    • Yessir, c'était juste un petit hack. 🙂
    • -1 pour la comparaison avec les optimisations désactivé. Il est trompeur et inutile.
    • Vous êtes à la comparaison d'un personnage, pas un pointeur. Oh pinaise!

    InformationsquelleAutor ctennis
  11. -2
    #include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{   
  char pointer[5];  
  /* This is insense you are comparing a pointer to a value */   
  if(pointer[0] == NULL) {     
    exit(1);
  } 
  ...
}

=>           ...    
  movzbl    9(%ebp), %eax  # your code compares a 1 byte value to a signed 4 bytes one 
  movsbl    %al,%eax        # Will result in sign extension...
  testl  %eax, %eax      
              ...

    Attention, gcc devrait avoir heurté un avertissement, si ce n'est le cas de la compilation avec -Wall drapeau sur
    Cependant, vous devriez toujours compiler à l'optimisation de gcc code.
    BTW, faites précéder votre variable avec le mot clé volatile afin d'éviter la gcc à partir de l'ignorer...

    De toujours mentionner votre compilateur version 🙂

    • Dans la question d'origine 'pointeur' est évidemment un tableau de pointeurs, pas de chars.
    InformationsquelleAutor ZeroCool