È sicuro usare -1 per impostare tutti i bit su true?

Ho visto questo schema usato molto in C & C ++.

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

È un buon modo portatile per farlo? O sta usando 0xffffffffo ~0meglio?

Ti consiglio di farlo esattamente come hai mostrato, poiché è il più diretto. Inizializza a -1cui funzionerà sempre , indipendentemente dalla rappresentazione del segno reale, mentre ~a volte avrà un comportamento sorprendente perché dovrai avere il giusto tipo di operando. Solo allora otterrai il valore più alto di un unsignedtipo.

Per un esempio di una possibile sorpresa, considera questo:

unsigned long a = ~0u;

Non memorizzerà necessariamente un modello con tutti i bit 1 in a. Ma prima creerà un modello con tutti i bit 1 in un unsigned int, quindi lo assegnerà a a. Quello che succede quando unsigned longha più bit è che non tutti sono 1.

E considera questo, che fallirà nella rappresentazione del complemento di un non-due:

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

La ragione di ciò è che ~0deve invertire tutti i bit. Inversione che produrrà -1su una macchina a complemento a due (che è il valore di cui abbiamo bisogno!), Ma non produrrà -1su un'altra rappresentazione. Sulla macchina di un complemento, produce zero. Pertanto, su una macchina del complemento di uno, quanto sopra verrà inizializzato aa zero.

La cosa che dovresti capire è che si tratta di valori, non di bit. La variabile è inizializzata con un valore . Se nell'inizializzatore si modificano i bit della variabile utilizzata per l'inizializzazione, il valore verrà generato in base a tali bit. Il valore necessario, per inizializzare aal valore più alto possibile, è -1o UINT_MAX. Il secondo dipenderà dal tipo di a- dovrai usare ULONG_MAXper un unsigned long. Tuttavia, il primo non dipenderà dal suo tipo ed è un bel modo per ottenere il valore più alto.

Stiamo Non parlando di se -1ha tutti i bit uno (non sempre ha). E non stiamo parlando del fatto che abbia tutti i bit uno (ovviamente ce l'~0 ha).

Ma quello di cui stiamo parlando è il risultato della flagsvariabile inizializzata . E per questo, funzionerà solo-1 con ogni tipo e macchina.

• unsigned int flags = -1; è portatile.
• unsigned int flags = ~0; non è portatile perché si basa su una rappresentazione a due complementi.
• unsigned int flags = 0xffffffff; non è portatile perché presuppone ints a 32 bit.

Se si desidera impostare tutti i bit in un modo garantito dallo standard C, utilizzare il primo.

Francamente penso che tutte le fff siano più leggibili. Per quanto riguarda il commento che è un antipattern, se ti interessa davvero che tutti i bit siano impostati / cancellati, direi che probabilmente ti trovi in ​​una situazione in cui ti preoccupi comunque della dimensione della variabile, che richiederebbe qualcosa come boost :: uint16_t, ecc.

Un modo per evitare i problemi menzionati è semplicemente fare:

unsigned int flags = 0;
flags = ~flags;

Portatile e al punto.

Non sono sicuro che usare un int senza segno per le bandiere sia una buona idea in primo luogo in C ++. Che dire di bitset e simili?

std::numeric_limit<unsigned int>::max()è migliore perché 0xffffffffpresuppone che int senza segno sia un numero intero a 32 bit.

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

"È un buon [,] modo portatile per raggiungere questo obiettivo?"

Portatile? Sì .

Buona? Discutibile , come evidenziato da tutta la confusione mostrata su questo thread. Essere abbastanza chiari che i tuoi colleghi programmatori possano capire il codice senza confusione dovrebbero essere una delle dimensioni che misuriamo per un buon codice.

Inoltre, questo metodo è soggetto agli avvisi del compilatore . Per eludere l'avvertimento senza paralizzare il compilatore, avresti bisogno di un cast esplicito. Per esempio,

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

Il cast esplicito richiede di prestare attenzione al tipo di destinazione. Se stai prestando attenzione al tipo di bersaglio, eviterai naturalmente le insidie ​​degli altri approcci.

Il mio consiglio è di prestare attenzione al tipo di target e assicurarsi che non vi siano conversioni implicite. Per esempio:

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

Tutto ciò è corretto e più ovvio per i tuoi colleghi programmatori.

E con C ++ 11 : possiamo usare autoper rendere ancora più semplice una di queste:

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

Considero corretto e ovvio meglio che semplicemente corretto.

La conversione di -1 in qualsiasi tipo senza segno è garantita dallo standard per ottenere tutti. L'uso di ~0Uè generalmente negativo poiché 0ha tipo unsigned inte non riempirà tutti i bit di un tipo più grande senza segno, a meno che non si scriva esplicitamente qualcosa del genere ~0ULL. Su sistemi sani, ~0dovrebbe essere identico a -1, ma poiché lo standard consente rappresentazioni di complemento e segno / grandezza, a rigor di termini non è portatile.

Ovviamente va sempre bene scrivere 0xffffffffse sai che hai bisogno esattamente di 32 bit, ma -1 ha il vantaggio che funzionerà in qualsiasi contesto anche quando non conosci le dimensioni del tipo, come le macro che funzionano su più tipi o se la dimensione del tipo varia in base all'implementazione. Se si conosce il tipo, un altro modo sicuro per ottenere tutti-quelli è la macro limite UINT_MAX, ULONG_MAX, ULLONG_MAX, etc.

Personalmente uso sempre -1. Funziona sempre e non devi pensarci.

Finché hai #include <limits.h>una delle tue inclusioni, dovresti semplicemente usare

unsigned int flags = UINT_MAX;

Se vuoi un pezzo di bit, potresti usare

unsigned long flags = ULONG_MAX;

A questi valori è garantito che tutti i bit di valore del risultato siano impostati su 1, indipendentemente da come vengono implementati gli interi con segno.

Sì. Come menzionato in altre risposte, -1è il più portatile; tuttavia, non è molto semantico e attiva gli avvisi del compilatore.

Per risolvere questi problemi, prova questo semplice aiuto:

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;

Non farei la cosa -1. È piuttosto non intuitivo (almeno per me). L'assegnazione di dati firmati a una variabile non firmata sembra essere una violazione dell'ordine naturale delle cose.

Nella tua situazione, io uso sempre 0xFFFF. (Usa il numero giusto di F per la dimensione variabile del corso.)

[A proposito, vedo molto raramente il trucco -1 fatto nel codice del mondo reale.]

Inoltre, se si interessa davvero i singoli bit in un vairable, sarebbe buona idea per iniziare a utilizzare il fixed-width uint8_t, uint16_t, uint32_ttipi.

Sui processori Intel IA-32 è OK scrivere 0xFFFFFFFF in un registro a 64 bit e ottenere i risultati previsti. Questo perché IA32e (l'estensione a 64 bit di IA32) supporta solo gli immediati a 32 bit. Nelle istruzioni a 64 bit gli immediati a 32 bit sono estesi a 64 bit.

Quanto segue è illegale:

mov rax, 0ffffffffffffffffh

Quanto segue inserisce 64 1 in RAX:

mov rax, 0ffffffffh

Solo per completezza, quanto segue inserisce 32 1 nella parte inferiore di RAX (aka EAX):

mov eax, 0ffffffffh

E infatti ho avuto problemi con i programmi quando volevo scrivere 0xffffffff in una variabile a 64 bit e invece ho ottenuto uno 0xffffffffffffffff. In C questo sarebbe:

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

il risultato è:

x is 0xffffffffffffffff

Ho pensato di postare questo come commento a tutte le risposte che dicevano che 0xFFFFFFFF assume 32 bit, ma così tante persone hanno risposto che ho pensato di aggiungerlo come risposta separata.

Vedi la risposta di litb per una spiegazione molto chiara dei problemi.

Il mio disaccordo è che, molto rigorosamente, non ci sono garanzie per entrambi i casi. Non conosco alcuna architettura che non rappresenti un valore senza segno di "uno inferiore a due alla potenza del numero di bit" come tutti i bit impostati, ma ecco cosa dice lo standard (3.9.1 / 7 plus nota 44):

Le rappresentazioni dei tipi integrali definiscono i valori mediante un sistema di numerazione binaria pura. [Nota 44:] Una rappresentazione posizionale per numeri interi che utilizza le cifre binarie 0 e 1, in cui i valori rappresentati dai bit successivi sono additivi, iniziano con 1 e vengono moltiplicati per la potenza integrale successiva di 2, tranne forse per il bit con la posizione più alta.

Ciò lascia la possibilità che uno dei bit sia qualsiasi cosa.

Sebbene 0xFFFF(o 0xFFFFFFFF, ecc.) Possa essere più facile da leggere, può interrompere la portabilità nel codice che altrimenti sarebbe portabile. Si consideri, ad esempio, una routine di libreria per contare quanti elementi in una struttura di dati hanno determinati bit impostati (i bit esatti specificati dal chiamante). La routine può essere totalmente agnostica su ciò che rappresentano i bit, ma deve comunque avere una costante "tutti i bit impostati". In tal caso, -1 sarà di gran lunga migliore di una costante esadecimale poiché funzionerà con qualsiasi dimensione di bit.

L'altra possibilità, se typedefsi utilizza un valore per la maschera di bit, sarebbe usare ~ (bitMaskType) 0; se la maschera di bit è solo un tipo di 16 bit, quell'espressione avrà solo 16 bit impostati (anche se 'int' sarebbe altrimenti 32 bit) ma poiché 16 bit saranno tutto ciò che è richiesto, le cose dovrebbero andare bene a condizione che uno utilizza effettivamente il tipo appropriato nel typecast.

Per inciso, le espressioni della forma longvar &= ~[hex_constant]hanno un gotcha cattivo se la costante esadecimale è troppo grande per adattarsi a un int, ma si adatta a un unsigned int. Se an intè 16 bit, allora longvar &= ~0x4000;oppure longvar &= ~0x10000; cancellerà un bit di longvar, ma longvar &= ~0x8000;cancellerà il bit 15 e tutti i bit sopra di esso. Ai valori che rientrano intverrà applicato l'operatore complemento a un tipo int, ma il risultato verrà esteso a long, impostando i bit superiori. I valori troppo grandi per unsigned intcui l'operatore del complemento verrà applicato al tipo long. I valori compresi tra quelle dimensioni, tuttavia, applicheranno l'operatore complemento al tipo unsigned int, che verrà quindi convertito in tipo longsenza estensione del segno.

Praticamente: Sì

Teoricamente: No.

-1 = 0xFFFFFFFF (o qualunque dimensione un int sia sulla tua piattaforma) è vero solo con l'aritmetica del complemento a due. In pratica, funzionerà, ma ci sono macchine legacy là fuori (mainframe IBM, ecc.) In cui hai un bit di segno reale piuttosto che una rappresentazione di complemento a due. La tua soluzione ~ 0 proposta dovrebbe funzionare ovunque.

Come altri hanno già detto, -1 è il modo corretto di creare un numero intero che verrà convertito in un tipo senza segno con tutti i bit impostati su 1. Tuttavia, la cosa più importante in C ++ sta usando i tipi corretti. Pertanto, la risposta corretta al tuo problema (che include la risposta alla domanda che hai posto) è questa:

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

Questo conterrà sempre l'esatta quantità di bit necessari. Costruisce a std::bitsetcon tutti i bit impostati su 1 per gli stessi motivi menzionati in altre risposte.

È sicuramente sicuro, poiché -1 avrà sempre tutti i bit disponibili impostati, ma mi piace ~ 0 meglio. -1 non ha molto senso per un unsigned int. 0xFF... non va bene perché dipende dalla larghezza del tipo.

Dico:

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

Questo ti darà sempre il risultato desiderato.

Sfruttando il fatto che assegnare tutti i bit a uno per un tipo senza segno equivale a prendere il valore massimo possibile per il tipo dato
ed estendere l'ambito della domanda a tutti i tipi interi senza segno :

L'assegnazione di -1 funziona per qualsiasi tipo intero senza segno (unsigned int, uint8_t, uint16_t, ecc.) Sia per C che per C ++.

In alternativa, per C ++, puoi:

1. Includi <limits>e usastd::numeric_limits< your_type >::max()
2. Scrivi una funzione personalizzata personalizzata (ciò consentirebbe anche un controllo di integrità, ovvero se il tipo di destinazione è davvero un tipo senza segno)

Lo scopo potrebbe essere quello di aggiungere più chiarezza, poiché l'assegnazione -1avrebbe sempre bisogno di un commento esplicativo.

Un modo per rendere il significato un po 'più ovvio e tuttavia evitare di ripetere il tipo:

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

sì, la rappresentazione mostrata è molto corretta, come se lo facessimo in senso contrario, dovrai richiedere a un operatore di invertire tutti i bit, ma in questo caso la logica è abbastanza semplice se consideriamo la dimensione degli interi nella macchina

ad esempio nella maggior parte delle macchine un numero intero è 2 byte = 16 bit il valore massimo che può contenere è 2 ^ 16-1 = 65535 2 ^ 16 = 65536

0% 65536 = 0 -1% 65536 = 65535 che corrisponde a 1111 ............. 1 e tutti i bit sono impostati su 1 (se consideriamo le classi di residui mod 65536) quindi è molto dritto.

suppongo

no, se consideri questa nozione, è perfetta per gli ints non firmati e funziona davvero

basta controllare il seguente frammento di programma

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;

}

risposta per b = 4294967295 che è -1% 2 ^ 32 su numeri interi a 4 byte

quindi è perfettamente valido per numeri interi senza segno

in caso di discrepanze si prega di segnalare