¿Es seguro usar -1 para establecer todos los bits en true?

• unsigned int flags = -1; es portátil.
• unsigned int flags = ~0; no es portátil porque se basa en una representación de dos complementos.
• unsigned int flags = 0xffffffff; no es portátil porque asume ints de 32 bits.

Si desea establecer todos los bits de una manera garantizada por el estándar C, use el primero.

Francamente creo que todos los fff's son más legibles. En cuanto al comentario de que es un antipatrón, si realmente te importa que todos los bits estén configurados/despejados, argumentaría que probablemente estés en una situación en la que te importe el tamaño de la variable de todos modos, lo que requeriría algo como boost::uint16_t, etc.

Una forma de evitar los problemas mencionados es simplemente hacer:

unsigned int flags = 0;
flags = ~flags;

Portátil y al grano.

No estoy seguro de que usar un int sin signo para las banderas sea una buena idea en primer lugar en C++. ¿Qué acerca de bitset y similares?

std::numeric_limit<unsigned int>::max() es mejor porque 0xffffffff asume que unsigned int es un entero de 32 bits.

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

"¿Es esta una buena[,] manera portátil de lograr esto?"

Portátil? Sí.

Bueno? Discutible, como lo demuestra toda la confusión mostrada en este hilo. Ser lo suficientemente claro para que sus compañeros programadores puedan entender el código sin confusión debería ser una de las dimensiones que medimos para un buen código.

Además, este método es propenso a advertencias del compilador. Para eludir la advertencia sin paralizar su compilador, necesitarías un elenco explícito. Por ejemplo,

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

El cast explícito requiere que prestes atención al tipo de destino. Si estás prestando atención al tipo de objetivo, entonces naturalmente evitarás las trampas de los otros enfoques.

Mi consejo sería prestar atención al tipo de destino y asegurarse de que no hay conversiones implícitas. Por ejemplo:

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);

Todos los cuales son correctos y más obvios para sus compañeros programadores.

Y con C++11 : Podemos usar auto para hacer cualquiera de estos aún más simple:

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

Considero correcto y obvio mejor que simplemente correcto.

Convertir -1 en cualquier tipo sin signo es garantizado por el estándar para dar como resultado todos-unos. El uso de ~0U es generalmente malo ya que 0 tiene el tipo unsigned int y no llenará todos los bits de un tipo sin signo más grande, a menos que escriba explícitamente algo como ~0ULL. En sistemas sanos, ~0 debería ser idéntico a -1, pero dado que el estándar permite representaciones de complemento y signo/magnitud, estrictamente hablando no es portátil.

Por supuesto, siempre está bien escribir out 0xffffffff si sabe que necesita exactamente 32 bits, pero -1 tiene la ventaja de que funcionará en cualquier contexto incluso cuando no sepa el tamaño del tipo, como macros que funcionan en varios tipos, o si el tamaño del tipo varía según la implementación. Si conoce el tipo, otra forma segura de obtener todas las macros son las macros de límite UINT_MAX, ULONG_MAX, ULLONG_MAX, etc.

Personalmente siempre uso -1. Siempre funciona y no tienes que pensar en ello.

Sí. Como se mencionó en otras respuestas, -1 es el más portable; sin embargo, no es muy semántico y activa las advertencias del compilador.

Para resolver estos problemas, pruebe este sencillo ayudante:

static const struct All1s
{
    template<typename UnsignedType>
    inline operator UnsignedType(void) const
    {
        return static_cast<UnsignedType>(-1);
    }
} ALL_BITS_TRUE;

Uso:

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;

Mientras tengas #include <limits.h> como uno de tus includes, solo debes usar

unsigned int flags = UINT_MAX;

Si quieres un largo de bits, se podría utilizar

unsigned long flags = ULONG_MAX;

Se garantiza que estos valores tengan todos los bits de valor del resultado establecidos en 1, independientemente de cómo se implementen los enteros con signo.

No haría lo de -1. Es bastante no intuitivo (al menos para mí). Asignar datos firmados a una variable sin firmar parece ser una violación del orden natural de las cosas.

En tu situación, siempre uso 0xFFFF. (Por supuesto, utilice el número correcto de Fs para el tamaño variable.)

[POR cierto, rara vez veo el truco -1 hecho en código del mundo real.]

Además, si realmente te importan los bits individuales en un vairable, sería buena idea comenzar a usar el ancho fijo uint8_t, uint16_t, uint32_t tipos.

En los procesadores IA-32 de Intel está bien escribir 0xFFFFFFFF en un registro de 64 bits y obtener los resultados esperados. Esto se debe a que IA32e (la extensión de 64 bits a IA32) solo admite inmediatez de 32 bits. En instrucciones de 64 bits los inmediatos de 32 bits son signo extendido a 64 bits.

Lo siguiente es ilegal:

mov rax, 0ffffffffffffffffh

Lo siguiente pone 64 1s en RAX:

mov rax, 0ffffffffh

Solo para completar, lo siguiente pone 32 1s en la parte inferior de RAX (también conocido como EAX):

mov eax, 0ffffffffh

Y de hecho, he tenido programas fallan cuando quería escribir 0xffffffff a una variable de 64 bits y obtuve un 0xffffffffffffffff. En C esto sería:

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

El resultado es:

x is 0xffffffffffffffff

Pensé en publicar esto como un comentario a todas las respuestas que decían que 0xFFFFFFFF asume 32 bits, pero mucha gente respondió que pensé que lo añadiría como una respuesta separada.

Ver la respuesta de litb para una explicación muy clara de los problemas.

Mi desacuerdo es que, muy estrictamente hablando, no hay garantías para ninguno de los casos. No conozco ninguna arquitectura que no represente un valor sin signo de 'uno menos de dos a la potencia del número de bits' como todos los bits establecidos, pero esto es lo que el Estándar realmente dice (3.9.1 / 7 más nota 44):

Las representaciones de tipos integrales definirán valores mediante el uso de un binario puro sistema de numeración. [Nota 44:] Una representación posicional para enteros que utiliza los dígitos binarios 0 y 1, en la que los valores representados por bits sucesivos son aditivos, comienzan con 1, y se multiplican por la potencia integral sucesiva de 2, excepto quizás para el bit con la posición más alta.

Eso deja la posibilidad de que uno de los bits sea cualquier cosa.

Prácticamente: Sí

Teóricamente: No.

-1 = 0xFFFFFFFF (o cualquier tamaño que tenga un int en su plataforma) solo es verdadero con la aritmética de complemento de dos. En la práctica, funcionará, pero hay máquinas heredadas (mainframes de IBM, etc.).) donde tienes un bit de signo real en lugar de una representación de complemento de dos. La solución ~0 propuesta debería funcionar en todas partes.

Aunque el 0xFFFF (o 0xFFFFFFFF, etc.) puede ser más fácil de leer, puede romper la portabilidad en el código que de otro modo sería portátil. Considere, por ejemplo, una rutina de biblioteca para contar cuántos elementos en una estructura de datos tienen determinados bits establecidos (los bits exactos son especificados por el llamante). La rutina puede ser totalmente agnóstica en cuanto a lo que representan los bits, pero todavía necesita tener una constante "todos los bits establecidos". En tal caso, -1 será mucho mejor que una constante hexadecimal, ya que funcionará con cualquier tamaño.

La otra posibilidad, si se usa un valor typedef para la máscara de bits, sería usar ~(bitMaskType)0; si bitmask sucede que solo es un tipo de 16 bits, esa expresión solo tendrá 16 bits configurados (incluso si 'int' de otro modo sería 32 bits) pero como 16 bits serán todo lo que se requiere, las cosas deberían estar bien siempre que uno realmente use el tipo apropiado en el encasillamiento.

Por cierto, las expresiones de la forma longvar &= ~[hex_constant] tienen una mala atrapada si el maleficio constante es demasiado grande para caber en un int, pero cabrá en un unsigned int. Si un int es 16 bits, entonces longvar &= ~0x4000; o longvar &= ~0x10000; borrará un bit de longvar, pero longvar &= ~0x8000; borrará el bit 15 y todos los bits por encima de eso. Los valores que encajan en int tendrán el operador complemento aplicado a un tipo int, pero el resultado se extenderá a long, estableciendo los bits superiores. Los valores que son demasiado grandes para unsigned int tendrán el operador complemento aplicado al tipo long. Valores que se encuentran entre esos tamaños, sin embargo, aplicará el operador complemento a type unsigned int, que luego se convertirá a type long sin extensión de signo.

Como otros han mencionado, -1 es la forma correcta de crear un entero que se convertirá a un tipo sin signo con todos los bits establecidos en 1. Sin embargo, lo más importante en C++ es usar los tipos correctos. Por lo tanto, la respuesta correcta a su problema (que incluye la respuesta a la pregunta que hizo) es esta:

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

Esto siempre contendrá la cantidad exacta de bits que necesita. Construye un std::bitset con todos los bits establecidos en 1 por las mismas razones mencionadas en otras respuestas.

Es ciertamente seguro, ya que -1 siempre tendrá todos los bits disponibles establecidos, pero me gusta ~0 mejor. -1 simplemente no tiene mucho sentido para un unsigned int. 0xFF... no es bueno porque depende del ancho del tipo.

Yo digo:

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

Esto siempre le dará el resultado deseado.

Aprovechando el hecho de que asignar todos los bits a uno para un tipo sin signo es equivalente a tomar el valor máximo posible para el tipo dado,
y extendiendo el alcance de la pregunta a todos los tipos enteros sin signo :

Asignar -1 funciona para cualquier tipo entero sin signo (int sin signo, uint8_t, uint16_t, etc.) para C y C++.

Como alternativa, para C++, puede:

1. Incluir <limits> y utilizar std::numeric_limits< your_type >::max()
2. Escriba una función templada personalizada (Esto también permitiría una comprobación de cordura, es decir, si el tipo de destino es realmente un tipo sin signo)

El propósito podría ser agregar más claridad, ya que asignar -1 siempre necesitaría algún comentario explicativo.

Sí, la representación que se muestra es muy correcta, ya que si lo hacemos al revés, u requerirá un operador para revertir todos los bits, pero en este caso la lógica es bastante sencilla si consideramos el tamaño de los enteros en la máquina

Por ejemplo, en la mayoría de las máquinas, un entero es de 2 bytes = 16 bits el valor máximo que puede contener es 2^16-1=65535 2^16=65536

0%65536=0 -1% 65536 = 65535 que corresponde a 1111.............1 y todos los bits se establecen en 1 (si consideramos clases de residuos mod 65536) por lo tanto, es muy sencillo.

Supongo

No si u considerar esta noción es perfectamente dine para ints sin firmar y realmente funciona

Basta con comprobar el siguiente fragmento del programa

Int principal() {

unsigned int a=2;

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

unsigned int b=-1;

cout<<"\n"<<b;

getchar();

return 0;

}

Respuesta para b = 4294967295 whcih es -1% 2^32 en enteros de 4 bytes

Por lo tanto, es perfectamente válido para enteros sin signo

En caso de discrepancias plzz informe