Question

Je suis la conception d'une langue, et d'essayer de décider si true doit être 0x01 ou 0xFF. De toute évidence, toutes les valeurs non nulles seront convertis en vrai, mais je suis en train de décider de la représentation interne exacte.

Quels sont les avantages et les inconvénients de chaque choix?

Était-ce utile?

La solution

0 est faux parce que le processeur a un indicateur qui est activé lorsque le registre est mis à zéro.

Aucun autre drapeaux sont fixés sur une autre valeur (0x01, 0xff, etc.) - mais le drapeau zéro est définie sur false quand il y a une valeur non nulle dans le registre

Ainsi, les réponses ici définissant 0 comme prônant faux et tout le reste aussi vrai sont corrects.

Si vous voulez « définir » une valeur par défaut pour vrai, 0x01 est mieux que la plupart:

  • Il représente le même nombre dans toutes les longueurs de bits et signedness
  • Il ne nécessite que des tests un peu si vous voulez savoir s'il est vrai, si le drapeau est indisponible zéro, ou coûteux à utiliser
  • Pas besoin de se soucier de l'extension de signe lors de la conversion à d'autres types
  • Les expressions logiques et arithmétiques agissent de la même sur elle

-Adam

Autres conseils

Peu importe, tant qu'il satisfait aux règles de la représentation externe.

Je prendrais un soupçon de C ici, où faux est défini comme absolument 0 et vrai est défini comme faux pas. Cette distinction est importante, par rapport à une valeur absolue pour vrai. Sauf si vous avez un type qui a seulement deux états, vous devez tenir compte de toutes les valeurs dans ce type de valeur, ce qui est vrai, et ce qui est faux.

Pourquoi choisissez-vous que les valeurs non nulles sont vraies? En Ada vrai est vrai et faux est faux. Il n'y a pas de conversion de type implicite et de booléennes.

Utilisation de -1 a un avantage dans un langage faiblement typé - si vous gâcher et utiliser l'opérateur and bitwise au lieu de l'opérateur and logique, votre condition sera toujours évaluer correctement tant que l'un des opérandes a été converti en la représentation canonique booléenne. Ce n'est pas vrai si la représentation canonique est 1.

  0xffffffff & 0x00000010 == 0x00000010 (true)
  0xffffffff && 0x00000010 == 0xffffffff (true)

  0x00000001 & 0x00000010 == 0x00000000 (false)
  0x00000001 && 0x00000010 == 0xffffffff (true)

OMI, si vous voulez coller avec false = 0x00, vous devez utiliser 0x01. 0xFF est généralement:

  • un signe que certaines opérations déborda

ou

  • un marqueur d'erreur

Et dans les deux cas, cela signifie probablement false . D'où le retour * nix convention de valeur de executables, que true = 0x00, et une valeur non nulle est fausse.

-1 est plus long que pour taper 1 ...

En fin de compte, il n'a pas d'importance puisque 0 est faux et tout le reste est vrai, et vous ne serez jamais comparé à la représentation exacte de la vraie.

Modifier, pour ceux en bas de vote, s'il vous plaît expliquer pourquoi. Cette réponse est essentiellement le même que celui qui est actuellement évalué à +19. Voilà donc 21 voix différence pour ce qui est la même réponse de base.

Si c'est à cause du commentaire -1, il est vrai, la personne qui définit réellement « true » (par exemple: l'auteur du compilateur) va devoir utiliser -1 au lieu de 1, en supposant qu'ils ont choisi d'utiliser un représentation exacte. -1 va prendre plus de temps à taper que 1, et le résultat final sera le même. La déclaration est stupide, il était censé être stupide, parce qu'il n'y a pas de différence réelle entre les deux (1 ou -1).

Si vous allez marquer quelque chose de fournir au moins une baisse justification.

0xff est un choix étrange car il a une hypothèse implicite que 8 bits est votre unité de stockage minimum. Mais ce n'est pas rare de vouloir stocker des valeurs booléennes plus que compact.

Peut-être que vous voulez reformuler en pensant que les opérateurs booléens produisent quelque chose qui est juste un 0 ou 1 bit (qui fonctionne quel que soit l'extension de signe), ou est tout-zéros ou Télécopieurs (et dépend de l'extension de signe de signé quantités complément à deux pour maintenir à une longueur quelconque tout-ones).

Je pense que votre vie est plus simple avec 0 et 1.

Les pros sont pas, et les inconvénients n'y en a pas, aussi. Tant que vous fournissez une conversion automatique de type entier vers booléen, il sera arbitraire, donc il n'a pas vraiment d'importance chiffres que vous choisissez.

Par contre, si vous n'avez pas permis cette conversion automatique vous auriez un pro: vous n'auriez pas une règle tout à fait arbitraire dans votre langue. Vous auriez pas (7 - 4 - 3) == false ou 3 * 4 + 17 == "Hello" ou "Hi mom!" == Complex(7, -2).

Je pense que la méthode C est la voie à suivre. 0 signifie faux, rien d'autre signifie vrai. Si vous allez avec une autre carte pour vrai, il vous reste le problème d'avoir des valeurs indéterminées -. Qui ne sont ni vrais ni faux

Si cela est la langue que vous serez la compilation d'un jeu d'instructions spécifique qui a un soutien particulier pour une représentation particulière, alors je laisserais ce guide vous. Mais l'absence de toute information supplémentaire, pour une représentation interne « standard », je partirais avec -1 (tous des 1 en binaire). Cette valeur va bien à tout ce booléenne taille que vous voulez (seul bit, 8 bits, 16, etc.), et si vous cassez un « vrai » ou « faux » dans une plus petite « VRAI » ou « FAUX », il est encore le même. (Où, si vous avez cassé un VRAI = 0x0001 16 bits vous obtiendrez un faux = 0x00 et 0x01 = TRUE a).

Concevoir la langue de sorte que 0 est faux et non nul est vrai. Il n'y a pas besoin de « convertir » quoi que ce soit, et de penser « non nulle » au lieu d'une certaine valeur spécifique vous aider à écrire le code correctement.

Si vous avez des symboles intégrés comme « True » alors allez-y et choisissez une valeur, mais toujours penser « non nul est vrai » au lieu de « 0x01 est vrai ».

Tout ce que vous faites, une fois que vous sélectionnez vos valeurs ne les changent pas. En Forth 77, vrai et faux ont été définis comme 1 et 0. Ensuite, FORTH-83 les a considérés comme -1 et 0. Il y avait pas peu (bon ok, seulement quelques-uns, ce Forth nous parlons) problèmes causé par cela.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top