Est-il sûr d'utiliser -1 pour définir tous les bits sur true?

J'ai vu ce modèle beaucoup utilisé en C & C ++.

unsigned int flags = -1;  // all bits are true

Est-ce un bon moyen portable d'accomplir cela? Ou utilise-t-il 0xffffffffou ~0mieux?

Je vous recommande de le faire exactement comme vous l'avez montré, car c'est le plus simple. Initialiser à -1qui fonctionnera toujours , indépendamment de la représentation réelle du signe, alors que cela ~aura parfois un comportement surprenant car vous devrez avoir le bon type d'opérande. Ce n'est qu'alors que vous obtiendrez la valeur la plus élevée d'un unsignedtype.

Pour un exemple de surprise possible, considérez celle-ci:

unsigned long a = ~0u;

Il ne stockera pas nécessairement un motif avec tous les bits 1 dans a. Mais il créera d'abord un motif avec tous les bits 1 dans un unsigned int, puis l'attribuera a. Ce qui se passe quand il y unsigned longa plus de bits, c'est que tous ne valent pas 1.

Et considérez celui-ci, qui échouera sur une représentation de complément non-deux:

unsigned int a = ~0; // Should have done ~0u !

La raison en est qu'il ~0faut inverser tous les bits. Qui donnera à inverser -1sur une machine de complément à deux ( ce qui est la valeur dont nous avons besoin!), Mais pas céder -1à une autre représentation. Sur une machine à complément à un, cela donne zéro. Ainsi, sur une machine à complément à un, ce qui précède s'initialise aà zéro.

Ce que vous devez comprendre, c'est qu'il s'agit de valeurs - pas de bits. La variable est initialisée avec une valeur . Si dans l'initialiseur vous modifiez les bits de la variable utilisée pour l'initialisation, la valeur sera générée en fonction de ces bits. La valeur dont vous avez besoin pour initialiser aà la valeur la plus élevée possible est -1ou UINT_MAX. Le second dépendra du type de a- vous devrez utiliser ULONG_MAXpour un fichier unsigned long. Cependant, le premier ne dépendra pas de son type, et c'est un bon moyen d'obtenir la valeur la plus élevée.

Nous ne parlons pas de savoir si -1tous les bits sont un (ce n'est pas toujours le cas). Et nous ne parlons pas de savoir si ~0tous les bits sont un (il en a, bien sûr).

Mais ce dont nous parlons est le résultat de la flagsvariable initialisée . Et pour cela, seul-1 fonctionnera avec tous les types et machines.

• unsigned int flags = -1; est portable.
• unsigned int flags = ~0; n'est pas portable car il repose sur une représentation complémentaire à deux.
• unsigned int flags = 0xffffffff; n'est pas portable car il suppose des entiers 32 bits.

Si vous souhaitez définir tous les bits d'une manière garantie par le standard C, utilisez le premier.

Franchement, je pense que tous les fff sont plus lisibles. En ce qui concerne le commentaire selon lequel c'est un anti-modèle, si vous vous souciez vraiment que tous les bits soient définis / effacés, je dirais que vous êtes probablement dans une situation où vous vous souciez de la taille de la variable de toute façon, ce qui appellerait quelque chose comme boost :: uint16_t, etc.

Une manière qui évite les problèmes mentionnés est de faire simplement:

unsigned int flags = 0;
flags = ~flags;

Portable et précis.

Je ne suis pas sûr que l'utilisation d'un int non signé pour les indicateurs soit une bonne idée en premier lieu en C ++. Qu'en est-il de bitset et autres?

std::numeric_limit<unsigned int>::max()est mieux car 0xffffffffsuppose que unsigned int est un entier 32 bits.

unsigned int flags = -1;  // all bits are true

"Est-ce un bon moyen [,] portable d'accomplir cela?"

Portable? Oui .

Bien? Discutable , comme en témoigne toute la confusion montrée sur ce fil. Être suffisamment clair pour que vos collègues programmeurs puissent comprendre le code sans confusion devrait être l'une des dimensions que nous mesurons pour un bon code.

En outre, cette méthode est sujette aux avertissements du compilateur . Pour éluder l'avertissement sans paralyser votre compilateur, vous auriez besoin d'un cast explicite. Par exemple,

unsigned int flags = static_cast<unsigned int>(-1);

La distribution explicite nécessite que vous prêtiez attention au type de cible. Si vous faites attention au type de cible, vous éviterez naturellement les pièges des autres approches.

Mon conseil serait de faire attention au type de cible et de s'assurer qu'il n'y a pas de conversions implicites. Par exemple:

unsigned int flags1 = UINT_MAX;
unsigned int flags2 = ~static_cast<unsigned int>(0);
unsigned long flags3 = ULONG_MAX;
unsigned long flags4 = ~static_cast<unsigned long>(0);

Tout cela est correct et plus évident pour vos collègues programmeurs.

Et avec C ++ 11 : nous pouvons utiliser autopour rendre l'un de ceux-ci encore plus simple:

auto flags1 = UINT_MAX;
auto flags2 = ~static_cast<unsigned int>(0);
auto flags3 = ULONG_MAX;
auto flags4 = ~static_cast<unsigned long>(0);

Je considère comme correct et évident mieux que simplement correct.

La conversion de -1 en n'importe quel type non signé est garantie par la norme pour aboutir à tout-un. L'utilisation de ~0Uest généralement mauvaise car 0a type unsigned intet ne remplira pas tous les bits d'un type non signé plus grand, à moins que vous n'écriviez explicitement quelque chose comme ~0ULL. Sur des systèmes sains, ~0devrait être identique à-1 , mais comme la norme autorise les représentations complémentaires à un et signe / grandeur, à proprement parler, elle n'est pas portable.

Bien sûr, il est toujours acceptable d'écrire 0xffffffffsi vous savez que vous avez besoin d'exactement 32 bits, mais -1 a l'avantage qu'il fonctionnera dans n'importe quel contexte même lorsque vous ne connaissez pas la taille du type, comme les macros qui fonctionnent sur plusieurs types , ou si la taille du type varie selon l'implémentation. Si vous ne connaissez le type, un autre moyen sûr d'obtenir tous-ones est les macros limites UINT_MAX, ULONG_MAX, ULLONG_MAX, etc.

Personnellement, j'utilise toujours -1. Cela fonctionne toujours et vous n'avez pas à y penser.

Tant que vous avez l' #include <limits.h>un de vos includes, vous devez simplement utiliser

unsigned int flags = UINT_MAX;

Si vous voulez une valeur longue de bits, vous pouvez utiliser

unsigned long flags = ULONG_MAX;

Il est garanti que tous les bits de valeur du résultat sont définis sur 1, quelle que soit la manière dont les entiers signés sont implémentés.

Oui. Comme mentionné dans d'autres réponses, -1est le plus portable; cependant, il n'est pas très sémantique et déclenche des avertissements du compilateur.

Pour résoudre ces problèmes, essayez cette aide simple:

static const struct All1s
{
    template<typename UnsignedType>
    inline operator UnsignedType(void) const
    {
        static_assert(std::is_unsigned<UnsignedType>::value, "This is designed only for unsigned types");
        return static_cast<UnsignedType>(-1);
    }
} ALL_BITS_TRUE;

Usage:

unsigned a = ALL_BITS_TRUE;
uint8_t  b = ALL_BITS_TRUE;
uint16_t c = ALL_BITS_TRUE;
uint32_t d = ALL_BITS_TRUE;
uint64_t e = ALL_BITS_TRUE;

Je ne ferais pas la chose -1. C'est plutôt non intuitif (du moins pour moi). Assigner des données signées à une variable non signée semble simplement être une violation de l'ordre naturel des choses.

Dans votre situation, j'utilise toujours 0xFFFF. (Utilisez le bon nombre de F pour la taille variable bien sûr.)

[BTW, je vois très rarement l'astuce -1 en code réel.]

De plus, si vous tenez vraiment sur les bits individuels dans un vairable, ce serait une bonne idée de commencer à utiliser la largeur fixe uint8_t, uint16_t, uint32_ttypes.

Sur les processeurs IA-32 d'Intel, il est possible d'écrire 0xFFFFFFFF dans un registre 64 bits et d'obtenir les résultats attendus. En effet, IA32e (l'extension 64 bits de IA32) ne prend en charge que les instantanés 32 bits. Dans les instructions 64 bits, les instantanés 32 bits sont étendus à 64 bits.

Ce qui suit est illégal:

mov rax, 0ffffffffffffffffh

Ce qui suit met 64 1 dans RAX:

mov rax, 0ffffffffh

Juste pour être complet, ce qui suit met 32 ​​1 dans la partie inférieure de RAX (aka EAX):

mov eax, 0ffffffffh

Et en fait, des programmes ont échoué lorsque je voulais écrire 0xffffffff dans une variable 64 bits et que j'ai obtenu un 0xffffffffffffffff à la place. En C, ce serait:

uint64_t x;
x = UINT64_C(0xffffffff)
printf("x is %"PRIx64"\n", x);

le résultat est:

x is 0xffffffffffffffff

J'ai pensé à poster ceci comme un commentaire à toutes les réponses qui disaient que 0xFFFFFFFF supposait 32 bits, mais tellement de gens y ont répondu que j'ai pensé que je l'ajouterais comme réponse séparée.

Voir la réponse de litb pour une explication très claire des problèmes.

Mon désaccord est que, à strictement parler, il n'y a aucune garantie dans les deux cas. Je ne connais aucune architecture qui ne représente pas une valeur non signée de `` un de moins de deux à la puissance du nombre de bits '' comme tous les bits définis, mais voici ce que dit réellement la norme (3.9.1 / 7 plus note 44):

Les représentations des types intégraux doivent définir des valeurs en utilisant un système de numération binaire pur. [Note 44:] Une représentation positionnelle pour les entiers qui utilise les chiffres binaires 0 et 1, dans laquelle les valeurs représentées par des bits successifs sont additives, commencent par 1 et sont multipliées par une puissance intégrale successive de 2, sauf peut-être pour le bit avec la position la plus élevée.

Cela laisse la possibilité pour l'un des bits d'être n'importe quoi.

Bien que le 0xFFFF(ou 0xFFFFFFFF, etc.) puisse être plus facile à lire, il peut interrompre la portabilité du code qui serait autrement portable. Prenons, par exemple, une routine de bibliothèque pour compter le nombre d'éléments dans une structure de données dont certains bits sont définis (les bits exacts étant spécifiés par l'appelant). Le sous-programme peut être totalement indépendant de ce que représentent les bits, mais doit tout de même avoir une constante «tous les bits définis». Dans un tel cas, -1 sera bien meilleur qu'une constante hexadécimale car il fonctionnera avec n'importe quelle taille de bit.

L'autre possibilité, si une typedefvaleur est utilisée pour le masque de bits, serait d'utiliser ~ (bitMaskType) 0; si le masque de bits n'est qu'un type 16 bits, cette expression n'aura que 16 bits (même si 'int' serait autrement 32 bits) mais comme 16 bits seront tout ce qui est nécessaire, les choses devraient bien se passer à condition que utilise en fait le type approprié dans le transtypage.

Incidemment, les expressions du formulaire longvar &= ~[hex_constant]ont un mauvais piège si la constante hexadécimale est trop grande pour tenir dans un int, mais rentre dans un unsigned int. Si an intvaut 16 bits, alors longvar &= ~0x4000;ou longvar &= ~0x10000; effacera un bit de longvar, mais longvar &= ~0x8000;effacera le bit 15 et tous les bits au-dessus. Les valeurs qui s'intègrent intauront l'opérateur de complément appliqué à un type int, mais le résultat sera étendu au signe long, définissant les bits supérieurs. Les valeurs qui sont trop grandes pour unsigned intauront l'opérateur de complément appliqué au type long. Les valeurs comprises entre ces tailles appliqueront cependant l'opérateur de complément au type unsigned int, qui sera ensuite converti en type longsans extension de signe.

Pratiquement: oui

Théoriquement: non.

-1 = 0xFFFFFFFF (ou quelle que soit la taille d'un int sur votre plate-forme) n'est vrai qu'avec l'arithmétique du complément à deux. En pratique, cela fonctionnera, mais il existe des machines héritées (mainframes IBM, etc.) où vous avez un bit de signe réel plutôt qu'une représentation de complément à deux. La solution ~ 0 que vous proposez devrait fonctionner partout.

Comme d'autres l'ont mentionné, -1 est la manière correcte de créer un entier qui sera converti en un type non signé avec tous les bits mis à 1. Cependant, la chose la plus importante en C ++ est d'utiliser des types corrects. Par conséquent, la bonne réponse à votre problème (qui comprend la réponse à la question que vous avez posée) est la suivante:

std::bitset<32> const flags(-1);

Celui-ci contiendra toujours la quantité exacte de bits dont vous avez besoin. Il construit un std::bitsetavec tous les bits mis à 1 pour les mêmes raisons mentionnées dans d'autres réponses.

C'est certainement sûr, car -1 aura toujours tous les bits disponibles, mais j'aime mieux ~ 0. -1 n'a tout simplement pas beaucoup de sens pour un unsigned int. 0xFF... n'est pas bon car cela dépend de la largeur du type.

Je dis:

int x;
memset(&x, 0xFF, sizeof(int));

Cela vous donnera toujours le résultat souhaité.

Tirer parti du fait qu'affecter tous les bits à un pour un type non signé équivaut à prendre la valeur maximale possible pour le type donné
et à étendre la portée de la question à tous les non signés les types d'entiers :

L'affectation de -1 fonctionne pour tout type entier non signé signé (unsigned int, uint8_t, uint16_t, etc.) pour C et C ++.

Comme alternative, pour C ++, vous pouvez soit:

1. Comprendre <limits> et utiliserstd::numeric_limits< your_type >::max()
2. Ecrire une fonction basée sur un modèle personnalisé (cela permettrait également une vérification de la cohérence, c'est-à-dire si le type de destination est vraiment un type non signé)

L'objectif pourrait être d'ajouter plus de clarté, car l'attribution -1nécessiterait toujours des commentaires explicatifs.

Un moyen de rendre le sens un peu plus évident et pourtant d'éviter de répéter le type:

const auto flags = static_cast<unsigned int>(-1);

oui la représentation montrée est tout à fait correcte car si on le fait dans l'autre sens u nécessitera un opérateur pour inverser tous les bits mais dans ce cas la logique est assez simple si l'on considère la taille des entiers dans la machine

par exemple, dans la plupart des machines, un entier vaut 2 octets = 16 bits la valeur maximale qu'il peut contenir est 2 ^ 16-1 = 65535 2 ^ 16 = 65536

0% 65536 = 0-1% 65536 = 65535 qui correspond à 1111 ............. 1 et tous les bits sont mis à 1 (si l'on considère les classes de résidus mod 65536) donc c'est beaucoup simple.

j'imagine

non si vous considérez cette notion, il est parfaitement dîné pour les entiers non signés et cela fonctionne réellement

vérifiez simplement le fragment de programme suivant

int main() {

unsigned int a=2;

cout<<(unsigned int)pow(double(a),double(sizeof(a)*8));

unsigned int b=-1;

cout<<"\n"<<b;

getchar();

return 0;

}

réponse pour b = 4294967295 whcih est -1% 2 ^ 32 sur des entiers de 4 octets

il est donc parfaitement valable pour les entiers non signés

en cas de divergence, rapport plzz