Pourquoi les #define TRUE (1==1) dans un C boolean macro au lieu de simplement 1?

J'ai vu des définitions en C 

#define TRUE (1==1)
#define FALSE (!TRUE)

Est-ce nécessaire? Quel est l'avantage par rapport à la simple définition VRAI que 1, et FAUX que 0?

  • Et plus: #define TRUE (’/’/’/’); #define FALSE (’-’-’-’) (prises à partir de coding-guidelines.com/cbook/cbook1_1.pdf page 871)
  • Non, c'est de la paranoïa par le paumé^Wunderinformed, vraiment. En C, 1 et 0 faire en toutes circonstances, la même.
  • Ça veut dire quoi?
InformationsquelleAutor | 2013-06-09
  1. 153

    Cette approche permettra d'utiliser le boolean type (et de résoudre à true et false) si le compilateur prend en charge. (plus précisément, C++)

    Cependant, il serait préférable de vérifier si le C++ est en cours d'utilisation (par l'intermédiaire de la __cplusplus macro) et de réellement utiliser true et false.

    Dans un compilateur C, c'est l'équivalent de 0 et 1.

    (notez que la suppression des parenthèses peut briser ce en raison de l'ordre des opérations)

    • C'est incorrect, booléens ne sont pas utilisés ici. Le résultat de 1==1 est un int. (voir stackoverflow.com/questions/7687403/... .)
    • Même en C++, avec la boolean type?
    • La Question est marqué C, mais en effet en C++ les opérateurs relationnels retour true ou false.
    • Je suppose que ce code est écrit en C en-têtes afin de bien jouer avec le C++
    • C++ a la même conversion implicite de partie intégrante des valeurs booléennes, comme C est le cas, je ne vois pas comment ce lié à cela.
    • Si elle voulait jouer à nice avec le C++, il serait #define TRUE true et #define FALSE false chaque fois que __cplusplus est défini.
    • Mais vous n'avez pas à écrire l'en-tête - peut-être celui qui n'a pensé qu'il était intelligent.
    • Les conversions implicites ne s'appliquent pas dans les varargs contextes, de sorte que ce type de définition est bien là.
    • étant donné que les règles de la promotion ne s'applique dans les varargs, vous aurez ints en tout cas, pas booléens (sauf si vous avez bool plus grande que ints?).
    • les types boolean n'existe pas en langage C. C'est pourquoi vous avez besoin d'utiliser l'int 0 et 1
    • lire sur le C11.
    • Ok, je ne le saviez pas. Merci. Mais peut-être plus de code, il n'est pas en C11...
    • Malheureusement, beaucoup de développeur travaille encore avec les anciennes versions de C (pour diverses raisons), c'est donc un bon moyen d'être compatible avec les anciennes versions, au lieu de travailler uniquement avec "la dernière version".
    • deviner?" C'est une question et une réponse du site, pas de question et de le deviner.
    • Nous ne pouvons que deviner l'intention de la personne qui a écrit ce code.

    InformationsquelleAutor SLaks
  2. 136

    La réponse est la portabilité. Les valeurs numériques de TRUE et FALSE ne sont pas importantes. Ce est important est qu'un énoncé comme if (1 < 2) évalue à if (TRUE) et une déclaration comme if (1 > 2) évalue à if (FALSE).

    Accordée, dans C, (1 < 2) évalue à 1 et (1 > 2) évalue à 0, alors que d'autres l'ont dit, il n'y a pas de différence pratique autant que le compilateur est concerné. Mais en laissant le compilateur définir TRUE et FALSE selon ses propres règles, vous êtes en rendant leurs significations explicites pour les programmeurs, et vous êtes garantir la cohérence au sein de votre programme et de toute autre bibliothèque (en supposant que l'autre bibliothèque suit normes C ... vous seriez étonné de voir).

    Un Peu D'Histoire

    Quelques notions de base défini FALSE comme 0 et TRUE comme -1. Comme beaucoup de langues modernes, ils interprété une valeur non nulle, comme TRUE, mais ils évalué des expressions booléennes qui était vrai que -1. Leur NOT opération a été mise en œuvre par l'ajout de 1 et le retournement de la signer, parce que c'était efficace pour le faire de cette façon. Si "PAS de x" est devenu -(x+1). Un effet secondaire de ceci est qu'une valeur comme 5 évalue à TRUE, mais NOT 5 évalue à -6, qui est aussi TRUE! Trouver ce genre de bug n'est pas amusant.

    Meilleures Pratiques

    Compte tenu de la de facto règles que zéro est interprété comme FALSE et tout valeur non nulle est interprété comme TRUE, vous devriez jamais booléen-à la recherche des expressions pour TRUE ou FALSE. Exemples:

    if (thisValue == FALSE)  //Don't do this!
if (thatValue == TRUE)   //Or this!
if (otherValue != TRUE)  //Whatever you do, don't do this!

    Pourquoi? Parce que beaucoup de programmeurs utilisent le raccourci de traitement de ints comme bools. Ils ne sont pas les mêmes, mais les compilateurs permettent généralement il. Ainsi, par exemple, il est parfaitement légal d'écrire

    if (strcmp(yourString, myString) == TRUE)  //Wrong!!!

    Que semble légitime, et le compilateur sera heureux de l'accepter, mais il n'a probablement pas faire ce que vous voulez. C'est parce que la valeur de retour de strcmp() est

          0 si yourString == myString

        <0 si yourString < myString

        >0 si yourString > myString

    De sorte que la ligne ci-dessus renvoie TRUE uniquement lorsque yourString > myString.

    La bonne façon de le faire est soit

    //Valid, but still treats int as bool.
if (strcmp(yourString, myString))

    ou

    //Better: lingustically clear, compiler will optimize.
if (strcmp(yourString, myString) != 0)

    De la même façon:

    if (someBoolValue == FALSE)     //Redundant.
if (!someBoolValue)             //Better.
return (x > 0) ? TRUE : FALSE;  //You're fired.
return (x > 0);                 //Simpler, clearer, correct.
if (ptr == NULL)                //Perfect: compares pointers.
if (!ptr)                       //Sleazy, but short and valid.
if (ptr == FALSE)               //Whatisthisidonteven.

    Vous trouverez souvent, certains de ces "mauvais exemples" dans le code de production, et de nombreux programmeurs expérimentés ne jurent que par eux: ils travaillent, certains sont plus courtes que celles de leur (de manière affectée?) corriger des solutions de rechange, et les expressions idiomatiques sont presque universellement reconnu. Mais pensez-y: le "droit" des versions ne sont pas moins efficaces, ils sont garantis pour être portable, ils passent même la plus stricte linters, et même de nouveaux programmeurs vont comprendre.

    N'est pas la peine?

    • (1==1) n'est pas plus portable que les 1. Le compilateur propres règles sont celles du langage C, qui est clair et sans ambiguïté sur la sémantique de l'égalité et des opérateurs relationnels. Je n'ai jamais vu un compilateur obtenir ce genre de choses de mal.
    • En fait, la valeur retournée par strcmp est connu pour être inférieure, égale ou supérieure à 0. Il n'est pas garanti d'être -1, 0 ou 1 et il y a des plates-formes dans la nature qui n'est pas le retour de ces valeurs pour gagner de la vitesse de mise en œuvre. Donc, si strcmp(a, b) == TRUE puis a > b mais inverse implication pourrait pas tenir.
    • Tout à fait raison, merci d'avoir signalé l'erreur. J'ai corrigé ma description.
    • Peut-être la "portabilité" est un mauvais terme. Mais le fait est que (1==1) est une valeur booléenne; 1 ne l'est pas.
    • En C, (1==1) et 1 sont à la fois des expressions constantes de type int avec la valeur 1. Ils sont sémantiquement identiques. Je suppose que vous pouvez écrire du code qui s'adresse à des lecteurs qui ne le savent pas, mais où prend-elle fin?
    • La valeur numérique de TRUE certainement est important. C'est une partie cruciale de l'algèbre booléenne, qui définit de cette façon à garder une bonne correspondance entre les opérations booléennes et entier.
    • 'pas' 5 est, en effet, -6, au niveau bit.

    InformationsquelleAutor Adam Liss
  3. 50

    La (1 == 1) astuce est utile pour la définition des TRUE dans une manière qui est transparent pour le C, fournit encore mieux taper en C++. Le même code peut être interprété comme C ou C++ si vous avez écrit dans un dialecte appelé "Propre C" (qui compile soit en C ou C++) ou si vous êtes à la rédaction de l'API de fichiers d'en-tête qui peut être utilisé en C ou C++ programmeurs.

    Dans C les unités de traduction, 1 == 1 a exactement le même sens que 1; et 1 == 0 a le même sens que 0. Toutefois, dans le C++ unités de traduction, 1 == 1 a type bool. Ainsi, le TRUE macro définie de cette façon, s'intègre de mieux en C++.

    Un exemple de la façon dont il s'intègre mieux, c'est que par exemple si la fonction foo a surcharges pour int et pour bool, puis foo(TRUE) sera de choisir le bool de surcharge. Si TRUE est simplement défini comme 1, alors il ne fonctionne pas bien dans le C++. foo(TRUE) voulez le int surcharge.

    Bien sûr, C99 introduit bool, true, et false et ceux-ci peuvent être utilisés dans les fichiers d'en-tête que le travail avec le C99 et avec C.

    Cependant:

    • cette pratique de la définition TRUE et FALSE comme (0==0) et (1==0) est antérieure à C99.
    • il y a toujours de bonnes raisons de rester à l'écart de C99 et de travailler avec C90.

    Si vous travaillez dans un mélange de C et de C++ du projet, et ne veulent pas C99, de définir les bas-de-casse true, false et bool à la place.

    #ifndef __cplusplus
typedef int bool;
#define true (0==0)
#define false (!true)
#endif

    Cela étant dit, le 0==0 truc, c'était (est?) utilisé par certains programmeurs, même dans le code qui n'a jamais été destiné à interagir avec le C++ en aucune façon. Que ne pas acheter n'importe quoi et suggère que le programmeur a une incompréhension de la façon dont les booléens travail en C.

    Dans le cas où le C++ explication n'était pas claire, voici un programme de test:

    #include <cstdio>

void foo(bool x)
{
   std::puts("bool");  
}

void foo(int x)
{
   std::puts("int");  
}

int main()
{
   foo(1 == 1);
   foo(1);
   return 0;
}

    La sortie:

    bool
int

    Quant à la question à partir des commentaires de la façon dont sont surchargés C++ les fonctions pertinentes à des mélanges de programmation C et C++. Ces juste illustrer un type de différence. Une raison valable pour vouloir un true constante à bool lorsqu'il est compilé comme le C++ est propre diagnostic. À son plus haut niveau d'alerte, un compilateur C++ pourrait nous mettre en garde contre une conversion si on passe un entier comme un bool paramètre. Une des raisons de l'écriture Propre, C est pas seulement que notre code n'est plus portable (puisqu'il est compris par les compilateurs C++, non seulement les compilateurs C), mais l'on peut bénéficier de l'diagnostic opinions des compilateurs C++.

    • Excellent, et les moins appréciés de réponse. Il n'est pas du tout évident que les deux définitions de TRUE seront différents selon C++.
    • Comment sont surchargés fonctions pertinentes pour le code qui compile à la fois comme le C et le C++?
    • Ce n'est pas seulement à propos de la surcharge mais bon taper en général, la surcharge est juste le plus pratique exemple quand il entre en jeu. Des cours de code C++ sans surcharges, les modèles et toutes que "compliqué" trucs supprimés pour "C-compatibilité" n'a pas vraiment beaucoup de soins sur les types, mais cela ne signifie pas que l'on doit renverser le conceptuelle type de limitations dans une langue donnée.
    • Que voulez-vous dire "n'a pas vraiment beaucoup de soins sur les types"? Les Types sont au cœur du langage C; chaque expression, la valeur et l'objet dans un programme C a bien défini le type. Si vous souhaitez définir quelque chose de différent en C et en C++ (dans le rare cas où vous avez réellement besoin d'écrire du code qui compile à la fois comme le C et le C++), vous pouvez utiliser #ifdef __cplusplus pour exprimer votre intention beaucoup plus clairement.
    • Oui je sais l'importance des types de sont. C'est juste que sans tous les type-courant des choses comme la surcharge et les modèles, des choses comme la différenciation entre bool et int n'a pas beaucoup d'importance dans la pratique, puisqu'ils sont implicitement convertible à l'autre (et dans C en fait, "le même", notez les guillemets, tout de même) et il n'y a pas beaucoup de situations dans lesquelles vous avez vraiment besoin de disambuigate entre les deux. "pas beaucoup" a été probablement trop lourd, "beaucoup moins par rapport à code à l'aide de modèles et de surcharge" aurait été mieux peut-être.
    • vous souhaitez définir quelque chose de différent en C et en C++..." - je le sais, et je n'ai pas toujours l'avocat (0==0) comme moyen approprié pour définir un "indépendant de la langue" TRUE et je suis d'accord qu'un #ifdef __cplusplus bloc est beaucoup plus claire. Mais néanmoins, cette macro est une façon de le faire, même si ce n'est le meilleur. La seule chose qui a suscité mon commentaire a été vous de sauter sur les fonctions surchargées exemple, alors qu'il était juste que, un exemple pour une plus inhérente et d'un problème conceptuel, la neccessity pour propery de frappe (qui vous, comme votre commentaire précédent suggère, également de haute valeur).
    • Je sais que certaines personnes (pour diverses raisons) ne se soucient pas de C99 ou plus récent, mais au moins votre définition de type de bloc doit vérifier si bool est déjà défini, dans ce cas, l'utilisation de cette définition, qui serait réel nettoyer C, tel qu'il compile sémantiquement l'égalité entre toutes les plates-formes et de toutes les normes ISO C ou C++ pour cette question

    InformationsquelleAutor Kaz
  4. 18
    #define TRUE (1==1)
#define FALSE (!TRUE)

    est équivalent à

    #define TRUE  1
#define FALSE 0

    dans C.

    Le résultat des opérateurs relationnels est 0 ou 1. 1==1 est garanti d'être évalué pour 1 et !(1==1) est garanti d'être évalué pour 0.

    Il n'y a absolument aucune raison d'utiliser la première forme. Notez que la première forme est cependant pas moins efficace que sur presque tous les compilateurs une expression constante est évaluée au moment de la compilation plutôt qu'au moment de l'exécution. C'est autorisé conformément à la présente règle:

    (C99, 6.6p2) "Une expression constante peut être évalué lors de la traduction plutôt que de l'exécution, et en conséquence peut être utilisé en tout lieu qu'une constante peut être."

    PC-Lint sera même question d'un message (506, la valeur de la constante booléenne) si vous n'utilisez pas un littéral pour TRUE et FALSE macros:

    Pour C, TRUE doivent être définis afin d'être 1. Cependant, d'autres langues qui utilisent des quantités autres que 1, de sorte que certains programmeurs se sentent que !0 est de jouer en toute sécurité.

    Également en C99, la stdbool.h définitions booléenne macros true et false utiliser directement les littéraux:

    #define true   1
#define false  0
    • J'ai un doute, la VRAIE, est remplacé à chaque utilisation avec 1==1, alors que, juste à l'aide de 1 remplacera 1, n'est pas la première méthode supplémentaire de comparaison de surcharge... ou il est fait optimisé compilateur ?
    • des expressions constantes sont généralement évalués au moment de la compilation et donc ne pas faire de frais généraux.
    • 1==1 va à 1 au lieu d'un indéfini valeur différente de zéro?
    • 1==1 est garanti d'être évalué pour 1
    • Une chose que je ne comprends pas, puisque seulement false est nécessaire d'avoir une valeur spécifique, à savoir 0, alors pourquoi n'est-il pas coutume de définir false comme 0 et true comme (!0)?
    • c'est une bonne question. C'est important pour le code de la forme if(foo == true), qui va simplement de la mauvaise pratique de flat-out buggy.
    • par la définition de la ! de l'opérateur.
    • +1 pour souligner les dangers dans (x == TRUE) peut avoir une valeur de vérité que x.
    • J'ai fait le travail et a regardé les spec:
    • J'ai fait le travail et a regardé les spec: "Le && opérateur donne 1 si les deux opérandes de comparer l'inégalité à 0, sinon elle donne 0. Le résultat est de type int." Même la langue pour toutes les autres conditions. Source: flash-gordon.me.uk/ansi.c.txt Donc ce qui n'est pas 0 est vrai, mais une des comparaisons ou des opérateurs logiques renvoient toujours 1, et pas seulement une valeur différente de zéro.

    InformationsquelleAutor ouah
  5. 12

    De côté à partir de C++ (déjà mentionné), un autre avantage est pour les outils d'analyse statique. Le compilateur va faire disparaître les inefficacités, mais un analyseur statique peut utiliser son propre résumé types de distinguer entre les résultats de la comparaison et d'autres types d'entiers, de sorte qu'il sait implicitement que le VRAI doit être le résultat d'une comparaison et ne doivent pas être pris pour être compatible avec un entier.

    Évidemment C dit qu'ils sont compatibles, mais vous pouvez choisir d'interdire l'utilisation délibérée de cette fonctionnalité pour aider à mettre en évidence les bogues, par exemple, où quelqu'un peut avoir confondre & et &&, ou qu'ils ont raté leur ordre de priorité des opérateurs.

    • C'est un bon point, et peut-être certains de ces outils peuvent même prendre idiot code if (boolean_var == TRUE) par la voie de l'expansion à if (boolean_var == (1 == 1)) qui, grâce à la meilleure info de la (1 == 1) nœud tombe dans le modèle if (<*> == <boolean_expr>).
    InformationsquelleAutor sh1
  6. 3

    La pratique de différence a pas. 0 est évalué à false et 1 est évalué à true. Le fait que vous utilisez un expression booléenne (1 == 1) ou 1, de définir true, ne fait aucune différence. Ils ont tous les deux obtient évalué à int.

    Avis que la bibliothèque C standard fournit un en-tête spécifique pour définir les booléens: stdbool.h.

    • zéro évalue à true et zéro évalue à false...
    • correct. Où voyez-vous me dire le contraire?
    • bien sûr, vous n'avez pas... mais certaines personnes pourraient penser le contraire, surtout pour les nombres négatifs c'est pourquoi 🙂
    • Quoi? Vous avez à l'envers. true est évalué à 1 et false est évalué à 0. C ne savez pas à propos de native les types boolean, ils sont tout entiers.
    • En C, le relationnel et l'égalité des opérateurs de produire des résultats de type int, avec la valeur 0 ou 1. C t un type booléen (_Bool, avec une macro bool défini dans <stdbool.h>, mais qui n'a été ajouté en C99, qui n' pas changer la sémantique des opérateurs à l'utilisation du nouveau type.
    • Comme en 1999, de la norme, C t ont un natif de type booléen. Il est appelé _Bool, et <stdbool.h> a #define bool _Bool.
    • vous avez raison sur le 1 == 1 en cours d'évaluation comme int. Édité.

    InformationsquelleAutor Shoe
  7. 3

    Nous ne connaissons pas la valeur exacte que la VRAIE est égale à et les compilateurs peuvent avoir leurs propres définitions. Donc, ce que vous privode est d'utiliser le compilateur interne pour la définition. Ce n'est pas toujours nécessaire si vous avez de bonnes habitudes de programmation, mais peut éviter des problèmes pour certains mauvais style de codage, par exemple:

    si ( (a > b) == TRUE)

    Ce serait une catastrophe si vous mannually définir VRAI que 1, alors que la valeur TRUE est une autre.

    • En C, le > opérateur donne toujours 1 pour true, 0 pour faux. Il n'y a pas de possibilité de n'importe quel compilateur C obtenir cette erreur. L'égalité des comparaisons à TRUE et FALSE sont style pauvres; le ci-dessus est plus clairement écrit que if (a > b). Mais l'idée que les différents compilateurs C peut traiter la vérité et le faux différemment, c'est tout simplement faux.
    InformationsquelleAutor capiggue
  8. 2
    1. Élément de la liste

    Généralement dans le Langage de Programmation C, 1 est définie comme true et 0 est définie sur false. C'est pourquoi vous voyez la suite assez souvent: 

    #define TRUE 1 
#define FALSE 0

    Cependant, aucun numéro n'est pas égal à 0 serait évalué à vrai aussi dans une instruction conditionnelle. Par conséquent, en utilisant le ci-dessous: 

    #define TRUE (1==1)
#define FALSE (!TRUE)

    Vous pouvez simplement afficher explicitement que vous avez essayé de jouer la sécurité en faisant de fausses égal à ce qui n'est pas vrai.

    • Je n'appellerais pas ça "jouer la sécurité"--ou plutôt, vous êtes vous donnant un faux sentiment de sécurité.
    • Supposons que votre...mise à jour de ma réponse
    InformationsquelleAutor Sabashan Ragavan