É seguro usar -1 para definir todos os bits como verdadeiros?

Eu já vi esse padrão usado muito em C & C ++.

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

Essa é uma boa maneira portátil de fazer isso? Ou está usando 0xffffffffou ~0melhor?

Eu recomendo que você faça exatamente como demonstrou, pois é o mais direto. Inicialize para o -1qual sempre funcionará , independentemente da representação real do sinal, enquanto ~às vezes terá um comportamento surpreendente, pois você precisará ter o tipo certo de operando. Somente então você obterá o valor mais alto de um unsignedtipo.

Para um exemplo de uma possível surpresa, considere este:

unsigned long a = ~0u;

Não necessariamente armazenará um padrão com todos os bits 1 a. Mas ele primeiro criará um padrão com todos os bits 1 em um unsigned inte depois o atribuirá a. O que acontece quando unsigned longhá mais bits é que nem todos são 1.

E considere este, que falhará na representação do complemento de um não-dois:

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

A razão para isso é que ~0é necessário inverter todos os bits. Invertendo que irá produzir -1na máquina de complemento de dois (que é o valor que precisamos!), Mas não deu -1em outra representação. Na máquina de complemento de uma pessoa, ela produz zero. Assim, na máquina de complemento de uma pessoa, o acima será inicializado acomo zero.

O que você deve entender é que se trata de valores - não de bits. A variável é inicializada com um valor . Se no inicializador você modificar os bits da variável usada para inicialização, o valor será gerado de acordo com esses bits. O valor que você precisa, para inicializar acom o maior valor possível, é -1ou UINT_MAX. O segundo dependerá do tipo de a- você precisará usar ULONG_MAXpara um unsigned long. No entanto, o primeiro não dependerá do seu tipo e é uma ótima maneira de obter o valor mais alto.

Estamos não falar sobre se -1tem todos os bits um (que nem sempre tem). E nós estamos não falar sobre se ~0tem todos os bits um (ele tem, é claro).

Mas o que estamos falando é qual é o resultado da flagsvariável inicializada . E, para isso, apenas-1 funcionará com todos os tipos e máquinas.

• unsigned int flags = -1; é portátil.
• unsigned int flags = ~0; não é portátil porque depende de uma representação de complemento de dois.
• unsigned int flags = 0xffffffff; não é portátil porque assume entradas de 32 bits.

Se você deseja definir todos os bits de uma maneira garantida pelo padrão C, use o primeiro.

Francamente, acho que todos os fff's são mais legíveis. Quanto ao comentário de que é um antipadrão, se você realmente se importa que todos os bits estejam configurados / limpos, eu diria que você provavelmente está em uma situação em que se importa com o tamanho da variável de qualquer maneira, o que exigiria algo como aumento :: uint16_t, etc.

Uma maneira de evitar os problemas mencionados é simplesmente fazer:

unsigned int flags = 0;
flags = ~flags;

Portátil e direto ao ponto.

Não tenho certeza de que usar um int não assinado para sinalizadores seja uma boa idéia em primeiro lugar em C ++. E quanto ao bitset e afins?

std::numeric_limit<unsigned int>::max()é melhor porque 0xffffffffassume que int não assinado é um número inteiro de 32 bits.

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

"Essa é uma boa maneira portátil de fazer isso?"

Portátil? Sim .

Boa? Debatível , como evidenciado por toda a confusão mostrada neste tópico. Ser claro o suficiente para que seus colegas programadores possam entender o código sem confusão deve ser uma das dimensões que medimos para obter um bom código.

Além disso, esse método é propenso a avisos do compilador . Para eliminar o aviso sem danificar seu compilador, você precisa de uma conversão explícita. Por exemplo,

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

A conversão explícita exige que você preste atenção ao tipo de destino. Se você está prestando atenção ao tipo de alvo, evita naturalmente as armadilhas das outras abordagens.

Meu conselho seria prestar atenção ao tipo de destino e garantir que não haja conversões implícitas. Por exemplo:

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 os quais são corretos e mais óbvios para seus colegas programadores.

E com o C ++ 11 : podemos usar autopara tornar ainda mais simples:

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

Considero correto e óbvio melhor do que simplesmente correto.

A conversão de -1 em qualquer tipo não assinado é garantida pelo padrão para resultar em todos. O uso de ~0Ugeralmente é ruim, pois 0tem tipo unsigned inte não preenche todos os bits de um tipo maior não assinado, a menos que você escreva explicitamente algo como ~0ULL. Em sistemas sãos, ~0deve ser idêntico a -1, mas como o padrão permite representações de complemento de unidades e sinal / magnitude, estritamente falando, não é portátil.

É claro que é sempre bom escrever 0xffffffffse você sabe que precisa exatamente de 32 bits, mas -1 tem a vantagem de funcionar em qualquer contexto, mesmo quando você não conhece o tamanho do tipo, como macros que funcionam em vários tipos ou se o tamanho do tipo variar de acordo com a implementação. Se você não sabe o tipo, outra forma segura de obter todo-queridos é as macros limite UINT_MAX, ULONG_MAX, ULLONG_MAX, etc.

Pessoalmente eu sempre uso -1. Sempre funciona e você não precisa pensar nisso.

Contanto que você tenha #include <limits.h>uma de suas inclusões, use apenas

unsigned int flags = UINT_MAX;

Se você quiser um valor de bits longo, poderá usar

unsigned long flags = ULONG_MAX;

É garantido que esses valores tenham todos os bits de valor do resultado definidos como 1, independentemente de como números inteiros assinados sejam implementados.

Sim. Como mencionado em outras respostas, -1é o mais portátil; no entanto, não é muito semântico e dispara avisos do compilador.

Para resolver esses problemas, tente este simples auxiliar:

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;

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;

Eu não faria a coisa -1. É bastante não intuitivo (pelo menos para mim). Atribuir dados assinados a uma variável não assinada apenas parece ser uma violação da ordem natural das coisas.

Na sua situação, eu sempre uso 0xFFFF. (Use o número certo de Fs para o tamanho variável, é claro.)

[BTW, raramente vejo o truque -1 feito no código do mundo real.]

Além disso, se você realmente se preocupam com os bits individuais em um vairable, seria boa idéia para começar a usar a largura fixa uint8_t, uint16_t, uint32_ttipos.

Nos processadores IA-32 da Intel, não há problema em gravar 0xFFFFFFFF em um registro de 64 bits e obter os resultados esperados. Isso ocorre porque o IA32e (a extensão de 64 bits para o IA32) suporta apenas imediatos de 32 bits. Nas instruções de 64 bits, os imediatos de 32 bits são estendidos para 64 bits.

O seguinte é ilegal:

mov rax, 0ffffffffffffffffh

O seguinte coloca 64 1s em RAX:

mov rax, 0ffffffffh

Apenas para completar, o seguinte coloca 32 1s na parte inferior do RAX (aka EAX):

mov eax, 0ffffffffh

E, de fato, tive programas falhar quando quis escrever 0xffffffff em uma variável de 64 bits e, em vez disso, recebi um 0xffffffffffffffff. Em C, isso seria:

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

o resultado é:

x is 0xffffffffffffffff

Eu pensei em postar isso como um comentário em todas as respostas que diziam que 0xFFFFFFFF assume 32 bits, mas muitas pessoas responderam que eu achei que adicionaria como resposta separada.

Veja a resposta do litb para uma explicação muito clara dos problemas.

Meu desacordo é que, estritamente falando, não há garantias para nenhum dos casos. Não conheço nenhuma arquitetura que não represente um valor não assinado de 'um a menos do que dois à potência do número de bits' como todos os bits configurados, mas aqui está o que o Padrão realmente diz (3.9.1 / 7 mais nota 44):

As representações dos tipos integrais devem definir valores usando um sistema de numeração binária pura. [Nota 44:] Uma representação posicional para números inteiros que usa os dígitos binários 0 e 1, na qual os valores representados por bits sucessivos são aditivos, começam com 1 e são multiplicados pela potência integral sucessiva de 2, exceto talvez para o bit com a posição mais alta.

Isso deixa a possibilidade de um dos bits ser qualquer coisa.

Embora o 0xFFFF(ou 0xFFFFFFFFetc.) possa ser mais fácil de ler, ele pode quebrar a portabilidade no código que, de outra forma, seria portátil. Considere, por exemplo, uma rotina de biblioteca para contar quantos itens em uma estrutura de dados possuem determinados bits definidos (os bits exatos sendo especificados pelo chamador). A rotina pode ser totalmente independente do que os bits representam, mas ainda precisa ter uma constante "todos os bits definidos". Nesse caso, -1 será muito melhor que uma constante hexadecimal, pois funcionará com qualquer tamanho de bit.

A outra possibilidade, se um typedefvalor for usado para a máscara de bits, seria usar ~ (bitMaskType) 0; se a máscara de bits for apenas do tipo de 16 bits, essa expressão terá apenas 16 bits definidos (mesmo que 'int' seja de 32 bits), mas como 16 bits serão tudo o que é necessário, as coisas devem ficar bem, desde que uma realmente usa o tipo apropriado no typecast.

Aliás, as expressões do formulário longvar &= ~[hex_constant]têm uma pegadinha desagradável se a constante hexadecimal for muito grande para caber em um int, mas caberá em um unsigned int. Se um inttiver 16 bits, então longvar &= ~0x4000;ou longvar &= ~0x10000; limpará um bit de longvar, mas longvar &= ~0x8000;limpará o bit 15 e todos os bits acima dele. Os valores que se encaixam intterão o operador de complemento aplicado a um tipo int, mas o resultado será estendido para o sinal long, configurando os bits superiores. Valores grandes demais unsigned intterão o operador de complemento aplicado ao tipo long. Valores entre esses tamanhos, no entanto, aplicarão o operador complemento ao tipo unsigned int, que será convertido em tipo longsem extensão de sinal.

Praticamente: Sim

Teoricamente: Não.

-1 = 0xFFFFFFFF (ou qualquer que seja o tamanho de um int em sua plataforma) só é verdadeiro com a aritmética de complemento de dois. Na prática, funcionará, mas existem máquinas legadas por aí (mainframes da IBM etc.) nas quais você tem um bit de sinal real em vez da representação de complemento de dois. Sua solução proposta ~ 0 deve funcionar em qualquer lugar.

Como outros já mencionaram, -1 é a maneira correta de criar um número inteiro que será convertido em um tipo não assinado com todos os bits definidos como 1. No entanto, o mais importante em C ++ é usar tipos corretos. Portanto, a resposta correta para o seu problema (que inclui a resposta à pergunta que você fez) é a seguinte:

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

Isso sempre conterá a quantidade exata de bits que você precisa. Constrói a std::bitsetcom todos os bits definidos como 1 pelos mesmos motivos mencionados em outras respostas.

É certamente seguro, pois -1 sempre terá todos os bits disponíveis definidos, mas eu gosto de ~ 0 melhor. -1 simplesmente não faz muito sentido para um unsigned int. 0xFF... não é bom porque depende da largura do tipo.

Eu digo:

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

Isso sempre lhe dará o resultado desejado.

Aproveitar o fato de atribuir todos os bits a um para um tipo não assinado é equivalente a pegar o valor máximo possível para o tipo fornecido
e estender o escopo da pergunta a todos os tipos inteiros não assinados :

A atribuição de -1 funciona para qualquer tipo de número inteiro não assinado (int não assinado, uint8_t, uint16_t etc.) para C e C ++.

Como alternativa, para C ++, você pode:

1. Incluir <limits>e usarstd::numeric_limits< your_type >::max()
2. Escreva uma função de modelo personalizado (isso também permitiria alguma verificação de integridade, por exemplo, se o tipo de destino for realmente um tipo não assinado)

O objetivo poderia ser adicionar mais clareza, pois a atribuição -1sempre precisaria de alguns comentários explicativos.

Uma maneira de tornar o significado um pouco mais óbvio e evitar repetir o tipo:

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

sim, a representação mostrada é muito correta, como se o fizéssemos o contrário, exigindo que um operador inverta todos os bits, mas, neste caso, a lógica é bastante direta se considerarmos o tamanho dos números inteiros na máquina

por exemplo, na maioria das máquinas, um número inteiro é 2 bytes = 16 bits, o valor máximo que pode armazenar é 2 ^ 16-1 = 65535 2 ^ 16 = 65536

0% 65536 = 0 -1% 65536 = 65535 que corresponde a 1111 ............. 1 e todos os bits são definidos como 1 (se considerarmos as classes de resíduos mod 65536), portanto, é muito direto.

eu acho

não, se você considerar essa noção, ela é perfeita para entradas não assinadas e funciona

basta verificar o seguinte fragmento de programa

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;

}

resposta para b = 4294967295 que é -1% 2 ^ 32 em números inteiros de 4 bytes

portanto, é perfeitamente válido para números inteiros não assinados

em caso de qualquer discrepância plzz report