Je viens de commencer à apprendre C d'hier et j'ai rencontré un problème et je ne reçois pas pourquoi cela se produit.
Le code est celui-ci p> il devrait montrer pas égal mais il est toujours en train de montrer que le nombre est égal et j'ai également essayé d'autres chiffres à la place de l'INT A;
Si j'ignite la valeur de INT A = 13, puis si j'exécute la déclaration si (A = 13), il est vrai, mais si je fais la même chose avec 0 à la fois, il ne montre pas égal. P> p>
3 Réponses :
Vous attribuez Exemple: P> 13 code> à A code> à l'aide de l'opérateur d'affectation, = code>. Utilisez == code> pour des comparaisons. int a=0;
void main()
{
// Here, a is being checked to see if it is equal to the int 13.
// a=13 would be assigning 13 to a, and then checking to see if
// a is "truthy", or, not 0, which is why it was true for you every time.
if (a == 13) {
printf("Number Is Equal\n");
}else{
printf("Not Equal\n");
}
}
Je suis ouvert aux votes en bas avec une critique constructive, mais c'est la bonne réponse. Si je me trompe, j'aimerais savoir pourquoi!
void principal () code> n'est pas standard C.
Il compile, court, c'est ce que OP dans leur question et la solution ici aborde le problème de l'OP connaissait.
Et il définit un mauvais exemple. Tous les extraits de code présentés dans des réponses doivent être standard C.
Op n'a jamais spécifié si ce code est finalement compilé pour un environnement autonome ou hébergé. La standard C indique que le nom et le type de la fonction de démarrage sont définis pour les environnements autoportants. Il n'est pas probable que cela soit pour un environnement autoportant, mais si je faisais ce changement, je ferais des hypothèses sur l'environnement de l'OP.
Techniquement, je n'ai pas dévié de la norme C, jusqu'à ce que OP spécifie qu'elles sont dans un environnement hébergé. Jusqu'à ce qu'ils spécifient cela, cela ne devrait pas être un problème. Heck, si je mettais int Page principale code> dans ma réponse, quelqu'un voudrait voter pour le changer, disant "qui ne correspond pas à OP! Ils pourraient être dans un environnement autoportant!" On dirait que votre problème est avec la question, et non ma réponse.
@Joshuaschlichant: Quelqu'un qui vient littéralement commencé à apprendre la langue la veille est très probable i> (en fait, presque certainement) sur une implémentation hébergée. Il est préférable d'assumer hébergée sauf indication contraire.
Stackoverflow .Com / Questions / 4273507 / ... Oui, je sais que mon livre C préféré est plein de vide () code> mais ce n'est pas le temps que nous nous sommes éloignés de cela?
@Bathsheba Non, votre livre préféré est bien pire, il est plein de principal () code>. L'INT implicite n'est pas valide C et la parenthèse vide est un style obsolète depuis 1990. Void Main (VOID) CODE> est toutefois une forme courante définie par la mise en œuvre, utilisée dans tous les systèmes de freestanding. Voir Ceci .
@Bathsheba Ouais, bien sûr, ils étaient tous les deux très intelligents et talentueux, mais cela ne fait pas le bon livre par association.
@Johnbode & @bathsheba Je suis d'accord, l'OP n'est pas susceptible d'être dans un environnement autoportant. Je ne pouvais pas résister à souligner que cela reste techniquement correct cependant, car l'environnement n'a pas été spécifié (et la question de l'OP était vraiment sur l'opérateur d'affectation, que la réponse couvre). Avec cela, j'ai apprécié la conversation et je conviens que cela devrait être probablement int PRINCIP () code>. J'ai fait une édition en pointant cela avec une explication et j'espère avoir gagné votre vote Up :).
Ouais. Downvote converti en uppote.
ici Il devrait montrer non égal? p>
blockQuote> modifier ce p> à p>
si la condition code> est toujours true en raison de l'affectation A = 13 code> non nulle, vous devez Utilisez == code> à la place. p>
Vous écrivez Vous devez écrire A = 13 code>, qui attribue la valeur 13 à a. Comme il s'agit de non-zéro, il est également considéré comme vrai (zéro traduire en faux). P>
A == 13 code> à la place, en utilisant des panneaux à double égalité, pour des comparaisons. P>
= code> est affectation.a = 13 code> attribue 13 àA code> et la valeur de l'expression est13 code>, c'est-à-dire non pas 0. Vouliez-vous== < / code>? Probablement un duplicata pour cela quelque part, bien que difficile à rechercher lorsque vous ne connaissez pas les termes. (Les bons compilateurs vous avertiront d'une affectation dans unsi code> vérifiez la condition, n'ignorez pas ces avertissements.)= code> est l'opérateur d'affectation - vous attribuez 13 àA code>, qui évalue comme "vrai". Vous devez utiliser== code> pour comparer les valeurs -si (a == 13) code>N'y a-t-il pas une cible de dupe canonique pour ce genre de questions? On dirait que cela a été discuté un million de fois déjà ...
Je sais sur l'opérateur de comparaison, mais dans ce cas, je ne faisais pas la comparaison BCZ en comparaison, le code fonctionne comme prévu, mais je ne reçois pas cette chose que lorsque je fais INT A = 0 et si (A = 0), il tire la Sinon dit que je ne m'attendais pas et si j'écris Int A = 0 et si (A = 1 ou un nombre), il incendie si la déclaration.
@AYU: N'as-tu pas lu mon premier commentaire? La valeur de l'expression A = 0 est 0, la valeur d'A = 13 est 13. C'est cette propriété qui vous permet d'écrire des choses comme A = B = 13.
@Bathsheba, alors nous assignons la nouvelle valeur qui signifie 13 à A?
@AYU: Yup. C'est celui-là.
Ok, mais si nous faisons un = 0 dans les deux endroits qui signifie INT A = 0 et if (a = 0), alors pourquoi il montre non égal? S'il vous plaît ne soyez pas ennuyé ou frustré de ma question BCZ, je suis complètement nouveau à cela.
@AYU: Sérieusement, le moment est venu de lire ceci (et n'oubliez pas d'acheter une copie) dipmat.univpm.it/~demeio/public/.../a>
@Bathsheba ok je vais le lire et ensuite je posterai dans des commentaires si j'ai eu des questions
@AYU: Une fois que vous avez lu cela (et terminé les exemples d'exercices), vous répondrez aux questions!
@AYU - Dans un contexte booléen, 0 signifie "faux". Encore une fois,
si (a = 0) code> attribue i> 0 àa code>, et le résultat de l'expression est la valeur deA Code> Après l'affectation - c'est le même résultat que l'écrituresi (0) code>, ce qui signifie que la branchesinon code> est prise.Veuillez noter que le livre K & R est désespérément obsolète et rempli d'erreurs. Ce n'est pas quelque chose que je recommanderais à quiconque de lire, moins de tous les débutants.
Question a un problème expliqué, contient une extraction de code montrant ce que OP a essayé, Code Snippet est capable de répéter le problème de l'OP, la question avec le code de code conduit clairement à une solution -> Mettez en attente comme hors sujet. Je ne comprends pas ...