Campi bit, perché l'implementazione è specifica?

I bitfield C/C++ sembrano avere molta applicazione nei driver hardware e nei trasferimenti di rete binari. Tuttavia non sembrano essere ampiamente usati e sono generalmente scoraggiati, perché il layout binario effettivo è specifico per l'implementazione, come mostrato in questa citazione dallo standard C99 6.7.2.1/10 - "Specifici struttura e unione";Campi bit, perché l'implementazione è specifica?

Un'implementazione può allocare qualsiasi unità di memoria indirizzabile abbastanza grande da contenere un campo bit. Se rimane abbastanza spazio, un campo di bit che segue immediatamente un altro campo di bit in una struttura deve essere impacchettato in bit adiacenti della stessa unità. Se lo spazio insufficiente rimane, se un campo di bit che non si adatta viene inserito nell'unità successiva o si sovrappone alle unità adiacenti è definito dall'implementazione. L'ordine di assegnazione dei campi di bit all'interno di un'unità (ordine alto a basso ordine o basso ordine a alto ordine) è definito dall'implementazione. L'allineamento dell'unità di memoria indirizzabile non è specificato.

La mia domanda è piuttosto semplice; Perché il comitato ha deciso di lasciare che i campi di bit fossero qualcosa di specifico dell'implementazione, e quindi di renderlo un costrutto compilatore, che può essere usato principalmente per l'utilizzo ridotto della memoria, dove potrebbe essere usato in molti casi per fornire dei binari binari e libero sviluppatori dal codice bit-fiddling?

fonte

2013-07-18 Skeen

Posso immaginare alcune ragioni ... mi viene in mente l'endianità. Ma anche, inserendo un bitfield in parte in uno e in parte in un altro byte, si otterrebbe un _lot_ di impatto sulle prestazioni, cosicché il comitato ha deciso che i compilatori sono liberi di scegliere come farlo, magari in base alle preferenze dell'utente in termini di velocità o ottimizzazione delle dimensioni. –

Sono sicuro che il fatto che il numero di bit per byte non debba essere 8 ha qualcosa a che fare con esso. –

@Mr Lister: Per garantire che un campo sia allineato nel byte successivo e quindi non inizi nel mezzo di un byte, ci viene assegnato il campo del bit di dimensione zero, giusto? - Quindi questo è già nello standard. – Skeen

Per lo stesso motivo, molte altre cose non sono strettamente specificate dallo standard: per consentire la flessibilità di produrre un compilatore conforme per un gran numero di piattaforme e sistemi e avere ancora un compilatore EFFICIENTE.

In particolare, i bitfield che devono essere memorizzati in un particolare ordine di bit/byte renderebbero orribilmente lento su macchine il cui ordine di byte naturale è il "modo sbagliato".

Sì, significa che è un vero e proprio dolore alle spalle rendere i bitfield portatili su più archiectures e piattaforme. Se davvero ne hai bisogno, forse dovresti prendere in considerazione qualche altra soluzione ...

fonte

2013-07-18 12:48:03

Quindi, almeno nel mio mondo, questo significa che per evitare una funzione possibilmente lenta, sono finiti con una caratteristica per lo più inutilizzabile? – Skeen

No, è perfettamente utilizzabile, purché non si richiede ANCHE che sia perectly portatile. Nota che per molte architetture, la differenza principale sarà l'ordine dei byte, non l'ordine dei bit, quindi sei a posto finchè il processore è lo stesso. E sono sicuro che la maggior parte delle persone si lamenterebbe almeno a voce alta se non fosse efficiente (ma perfettamente portatile e ben definito). –

Probabilmente hai ragione, anche se preferirei avere un bitfield portatile ben definito, e poi fare il giocherellando io stesso, ogni volta che ho bisogno di prestazioni .. Rispetto al contrario. – Skeen

Campi bit, perché l'implementazione è specifica?

risposta

Problemi correlati