Perché le strutture impaccate non fanno parte del linguaggio C?

10

Ogni compilatore C offre la possibilità di "impacchettare" le strutture C (ad es __attribute__ ((__packed__)). Oppure #pragma pack()). Ora, sappiamo tutti che è necessario il confezionamento, se desideriamo inviare o archiviare i dati in modo affidabile. Questo deve essere stato anche un requisito fin dai primi giorni del linguaggio C.

Quindi mi chiedo perché le strutture impaccate non facciano parte delle specifiche del linguaggio C? Non sono nemmeno in C99 o C11 anche se la necessità di averli è nota da decenni ormai? Cosa mi manca? Perché è specifico del compilatore?

c

— grasbueschel
fonte

2

Non sono necessari per scrivere codice C puro.

— user253751

7

Immagino sia perché dipende dalla combinazione di CPU / compilatore target utilizzata. Ciò significa che è meglio essere una direttiva del compilatore (in quanto correlata a questo) piuttosto che un aspetto del linguaggio, perché come specificarlo? L'unico modo in cui potevano farlo è con l'unione.

L'articolo di Raymond fornisce alcuni spunti sul perché questo è: http://www.catb.org/esr/structure-packing/

— Frans Bouma
fonte

Articolo molto interessante. (+1)

— Giorgio,

Quale difficoltà ci sarebbe nel consentire al codice di dire "Ho bisogno di una struttura che contenga 12 byte; il campo X deve comportarsi come numero intero a 32 bit memorizzato come little-endian a quattro ottetti all'offset 0; il campo Y deve comportarsi come numero intero a 64 bit memorizzato come byte di ottetti little-endian con offset 4 "? Il codice per gestirlo su qualsiasi piattaforma non dovrebbe essere peggiore di quello che i compilatori devono già fare per i bitfield e nei casi in cui il programmatore specifica che l'allineamento che corrisponde alla macchina nativa potrebbe essere molto più efficiente. Su altre macchine, sarebbe meno efficiente ma comunque portatile.

— supercat,

5

Ci sono tre fattori principali.

Alcuni processori non possono accedere a dati non allineati (ad esempio un numero intero o float a partire da un indirizzo dispari). Il tentativo di fare innesca un'eccezione.
Alcuni processori possono accedere a dati non allineati, ma a un costo prestazionale.
Alla maggior parte delle strutture si accede da un singolo set di codice sorgente C / C ++ e l'interoperabilità con altre lingue è l'eccezione, non la regola.

Tenendo conto di questi fattori, sia i compilatori standard che tutti i compilatori C / C ++ sistemano regolarmente le strutture per garantire un allineamento ottimale per il processore, ma forniscono anche meccanismi per sovrascrivere questo se necessario ai fini dell'interoperabilità.

Questo non è affatto qualcosa che è stato trascurato. È estremamente ben compreso e la situazione attuale è di progettazione. Le ultime versioni dello standard C ++ offrono un ampio supporto per la gestione dei problemi di allineamento, che forse non conoscete.

— david.pfx
fonte

Qualsiasi argomento che potrebbe essere fatto contro strutture impaccate potrebbe anche essere usato per giustificare la trasformazione dei campi di bit in una funzione opzionale. L'accesso ai membri di strutture impacchettate sarebbe lento su alcuni processori, veloce su altri, ma fare in modo che i compilatori provino a sostituire le soluzioni alternative del codice utente per la mancanza di funzionalità di accesso non allineato con codice più efficiente è molto più complicato rispetto al semplice fatto che i compilatori consentano ai programmatori di specificare cosa loro hanno bisogno.

— supercat,

@supercat: per cosa stai discutendo (o contro)? Non capisco

— david.pfx,

Sono dell'opinione che i bitfield dovrebbero essere opzionali, ma se i bitfield saranno una caratteristica obbligatoria, sarebbe logico estenderli in un modo che consenta il controllo esplicito del layout della struttura. Altrimenti, l'effetto netto è che i compilatori devono fare il 90% del lavoro che sarebbe necessario per il pieno controllo del layout, ma i programmatori raccolgono solo il 10% del vantaggio.

— supercat,

@supercat: i bit-field sono numeri interi e seguono le stesse regole di ordinamento del layout dei bit degli interi: implementazione definita. I membri di Struct sono ordinati sui confini dei personaggi come dichiarato, possibilmente con il pacchetto inserito. Sono concettualmente abbastanza separati. [Dovrai fare un'altra domanda se vuoi espandere la tua proposta, ma non credo che funzionerebbe affatto.]

— david.pfx

0

È specifico del compilatore perché non è nello standard. E non è nello standard perché sarebbe difficile specificare in un modo che non richiederebbe molti sforzi di implementazione per i compilatori di piattaforme oscure con restrizioni di allineamento forzate.

E nessuno di questi sforzi ha molte giustificazioni, perché ogni compilatore / piattaforma a cui interessa chiunque utilizzi un compilatore C89 o successivo lo ha già implementato.

— Soru
fonte

2

??? Hai risposto alla domanda "Perché non è nella lingua standard" dicendo "perché non è nella norma" ...

— Emilio Garavaglia,

Questo è quello che ho pensato prima, ma poi, si potrebbe specificare la funzionalità come "se la struttura è definita con la parola chiave" compresso ", la sua dimensione è garantita uguale alla dimensione aggiunta di ogni singolo membro. Su piattaforme che non supportano accesso alla memoria non allineato, l'accesso a uno dei valori del membro struct è un comportamento indefinito. " Ciò consentirebbe agli sviluppatori su piattaforme senza accesso non allineato di conoscere almeno le dimensioni delle strutture e l'offset di ogni singolo membro ...

— grasbueschel

1

Sarebbe possibile far funzionare l'accesso non allineato su sistemi che non lo supportano nell'hardware implementando tali strutture come una matrice di byte ed eseguendo il necessario spostamento di bit e &/ |operazioni per leggere / scrivere i valori di ciascun campo.

— dan04,

1

@ dan04: su molti processori, un compilatore potrebbe generare codice per l'accesso non allineato che era più efficiente rispetto all'uso di una sequenza di letture e spostamenti di byte. Avere una sintassi per questo renderebbe più semplice per questi compilatori generare codice efficiente piuttosto che richiedere loro di riconoscere tutti i diversi modi in cui i programmatori potrebbero provare a scrivere codice per assemblare byte in tipi più lunghi.

— supercat,