en C, au moins chaque valeur positive sauf 0 est traitée comme une version booléenne. Mais qu'en est-il d'une valeur négative? J'ai fait des tests et il semble que les valeurs négatives sont également traitées comme une vraie Booléenne. Est-ce un comportement défini ou une implémentation spécifique? P>
(Je suis venu réfléchir à cela lorsque j'ai vu dans une question, une personne qui promouvait déclarer "vrai" et "faux" dans une énumération comme 1 et 0.) p>
5 Réponses :
Ceci est un comportement défini. Je chercherai le paragraphe standard de C99 indiquant en tant que tel p>
§ 6.3.1.2 B>
Lorsqu'une valeur scalaire est convertie en _bool, le résultat est 0 si La valeur se compare égale à 0; Sinon, le résultat est de 1. P> blockQuote>
+1 La norme bool code> est bonne. J'utilise un ENUM code> en cas de retombe au cas où un compilateur particulier manque de support C99.
en C, il n'y a pas de type booléen; 0 et 0.0f sont considérés comme "faux" dans des contextes booléens, tout le reste est "vrai".
déclarant "vrai" et "faux" dans un énorme est faux, car le code suivant se cassera: P> < Pré> xxx pré>
(2 devrait être évalué comme "vrai", mais si TRUE a été défini comme 1, les deux valeurs ne sont pas considérées comme égales). P> P>
Toute personne teste si une valeur est égale à true code> est fausse, car le test ne doit pas être fait en premier lieu. Un Enum code> est bien dans certaines situations.
Il y a un type booléen en C99, voir ma réponse
Être un nitpick ici, mais l'énumé, lorsqu'il est utilisé, ressemble à un type booléen approprié mais ne se comporte pas comme un. C'est pourquoi je préfère ne pas l'avoir en premier lieu et il suffit d'utiliser 0 et 1 à la place.
Assez juste. Je n'écrirais pas si (x == true) code> même s'il s'agissait d'un type booléen approprié. J'aime juste avoir un type booléen fonctionnel à revenir des fonctions parfois.
Je crois que 0 est faux et tout le reste est vrai. P>
Voir la réponse de @ Casper ici: Fil P>
Je prendrais un indice de C ici, où False est défini absolument comme 0 et est défini comme non fausse. Ceci est une distinction importante, par rapport à une valeur absolue pour le vrai. Sauf si vous avez un type qui n'a que deux États, vous devez prendre en compte toutes les valeurs de ce type de valeur, ce qui est vrai et ce qui est faux. P> blockQuote>
Ceci est le comportement correct, en C 0 fort> est
c définie 0 comme faux et tout le reste comme vrai. Positif, négatif, peu importe.
Je crois que j'ai récemment préconisé l'utilisation de i généralement perforez simplement ceci n'est pas meilleur que le type être aussi, selon quelqu'un d'autre ci-dessus, un meilleur Je pense que Typedef Enum {False, True} Bool; Code> Je vais donc posséder. (Si mon code d'origine n'avait pas de Typedef CODE> impliqué, c'était une erreur de jugement de ma part.) Toutes les valeurs non nulles sont vraies, donc je ne préconiserais pas à l'aide d'un énuméré bool code> Type pour des choses comme ceci: p> si (x) code> ou si (! x) < / code> à des tests explicites contre les valeurs booléennes. Cependant, il est parfois bon d'avoir un type booléen: p> int code>, mais au moins tu es Étant explicite avec ce que le résultat est censé. p> bool code> pourrait être le suivant: p> ! code> est garanti de retourner 0 ou 1, mais je pourrais avoir tort, et ce qui précède fonctionne bien de toute façon. p> p>
Juste ne fais pas ça. bool code>, true code> et false code> est défini dans "stdbool.h" et faire la bonne chose.
@Jens - Tous les systèmes n'auront pas de support C99, peut-être que le compilateur de quelqu'un est vraiment vieux ou est fabriqué par Microsoft, et il est si facile de définir un remplissage bool code> type au cas où quelqu'un n'en a pas que si vous allez utiliser un type bool code> en premier endroit, vous pourriez aussi bien avoir une sauvegarde.
Ensuite, vous feriez mieux de faire comment il est prévu dans C89, à savoir avoir int code> pour les valeurs booléennes. Et définissez votre remplacement dans un fichier séparé qui les définit sous forme de macros bool == int code>, false == 0 code> et true == 1 code>. Sinon, une fois que vous auriez un compilateur C99, ce serait une véritable douleur au port.
@Jens - En désaccord. Je ne pense pas que cela compte si vous les définissez comme des macros ou comme un Enum code> tant que vous le définissez pour fonctionner de même, utilisez-le de manière cohérente (c'est-à-dire aucune hypothèse sur la valeur de true code>, ne testez pas les valeurs code> BOOL code> contre BOOL code> valeurs, etc.), et définissez-la sous condition pour tout ce qui n'est pas supporté en C99, il n'y a aucun moyen de ne fonctionnera pas. Et bool code> n'est pas extrêmement utile de toute façon, alors même si quelque chose se casse, il ne peut pas vraiment casser trop mal.
Tout ce qui n'est pas
false code> estvrai code>?Je pense que ce Stackoverflow.com/ Questions / 727196 / ... répondrait à votre question