Perché le matrici a lunghezza variabile sono state rese opzionali in C 2011?

Quando sono stati introdotti i VLA in C 1999, ho pensato che fosse una grande innovazione nel linguaggio. Tuttavia, dopo aver appreso che è stato reso facoltativo in C 2011, mi chiedo cosa abbia portato al suo cambiamento di stato e se ciò significhi che la funzionalità è effettivamente destinata all'obsolescenza. In tal caso, esiste una nozione equivalente di gestione automatica dei dati di dimensioni dinamiche che viene presa in considerazione per sostituirli?

Ho tentato di trovare il documento di motivazione di C 2011, ma non sembra ancora essere stato pubblicato.

c language-features c11

— JXH
fonte

Mancanza di adozione?

— Ryan Reich,

@RyanReich: Probabilmente, ma perché la resistenza dei venditori?

— jxh,

Risposte:

Ho sentito che le leggende variano da "dovrebbe essere facoltativo in quanto alcuni piccoli compilatori dovrebbero essere in grado di essere conformi a C11 senza VLA" a "è stato un errore in primo luogo". Non ho mai avuto una risposta vera e definitiva a questo, però. In definitiva, non credo che qualcuno ne abbia davvero uno perché la ragione (supponendo - e sperando - ce n'è uno) non è mai stata rivelata (per quanto riguarda le mie vecchie ricerche).

Dal capitolo 4 (pagina 13) della motivazione dello standard internazionale - Linguaggi di programmazione - C 5.10 (2003)

Definendo implementazioni conformi in termini di programmi che accettano, lo Standard lascia aperta la porta a un'ampia classe di estensioni come parte di un'implementazione conforme. Definendo sia implementazioni hosted conformi che conformi freestanding, lo Standard riconosce l'uso di C per scrivere programmi come sistemi operativi e applicazioni basate su ROM, nonché applicazioni host più convenzionali. Al di là di questo schema a due livelli, non viene definito alcun sottoinsieme aggiuntivo per C, poiché il Comitato C89 ha ritenuto fortemente che troppi livelli diluiscono l'efficacia di uno standard .

Enfasi mia. Si noti che questa decisione è contraria alla propria logica. Eppure, un'altra cosa resa facoltativa. Ora ottieni __STDC_NO_VLA__o supporto VLA. È una decisione molto strana.

— Bernardo Sulzbach
fonte

@jxh Non l'ho nemmeno visto. Grazie per averlo sottolineato, è stato modificato in una formulazione più chiara e meno ambigua. Ho visto il motivo come sinonimo di movente e obiettivo in alcuni contesti, ma credo che sia comune solo negli scenari artistici.

— Bernardo Sulzbach,

Il problema di avere solo uno schema a due livelli è che ci sono molte funzioni e garanzie utili che sono ampiamente ma non del tutto universalmente supportate e che possono consentire a certi tipi di programmi di essere scritti in modo molto più efficiente di quanto sarebbe altrimenti possibile. La mancanza di qualsiasi mezzo standard di test per la disponibilità di tali funzionalità rende necessario per una frazione significativa, se non per la maggior parte dei programmi pratici in molti campi, di avvalersi di garanzie oltre a quelle incluse nello Standard e rende difficile determinare con certezza se qualche particolare ...

— supercat

... il programma funzionerà con qualsiasi implementazione particolare. La definizione di una più ampia gamma di funzionalità e garanzie opzionali che le implementazioni possono supportare o rifiutare (rifiutando la compilazione) consentirebbero di avere un modo semplice e standard di verificare se un programma che specifica correttamente i suoi requisiti funzionerà correttamente su una piattaforma: provare per costruirlo. Se si costruisce, funzionerà. In caso contrario, ovviamente non lo farà. Aumentare la frazione di programmi per i quali sarebbe possibile garantire che una build di successo garantirebbe un funzionamento di successo ...

— supercat

... sembrerebbe molto più prezioso della semplice massimizzazione del numero di compilatori in grado di gestire la minima parte di programmi che non trarrebbero beneficio da funzionalità e garanzie oltre a quanto richiesto dallo Standard.

— supercat,

Per quanto posso determinare dai documenti del comitato pubblico (in particolare N1395 ), uno dei motivi principali per rendere facoltativi i VLA (insieme a aritmetica e threading complessi) è stato quello di rendere possibile la creazione di compilatori C conformi per piccoli processori embedded.

La tendenza era che i produttori di compilatori che prendevano di mira i sistemi embedded rimanessero sullo standard C90, a causa dell'introduzione di quelle grandi funzionalità che i loro clienti non stavano chiedendo.

— Bart van Ingen Schenau
fonte

In molti casi, "stavano chiedendo di aver lasciato fuori". Una volta osservata la modifica dell'impronta RAM quando si abilitano tali funzionalità, diventa evidente il motivo per cui alcune persone non le vogliono. Può raddoppiare il costo del processore, che può essere la parte più costosa del sistema.

— ღ uі

@JerryCoffin: Sì, ma il codice viene generato solo quando sizeof () viene effettivamente utilizzato sull'array. Il compilatore deve tenere traccia delle informazioni in modo da poter generare il codice corretto, ma tali informazioni non devono essere incorporate nella rappresentazione in memoria del VLA.

— jxh,

@jxh: Come inizialmente previsto, le implementazioni indipendenti e ospitate utilizzavano lo stesso linguaggio di base. Le differenze erano limitate alla biblioteca. Nel caso dei VLA, c'è una differenza nella lingua stessa che (almeno alcuni fornitori ritengono) non proprio adatta a sistemi embedded più piccoli. Per quanto riguarda l'incorporamento delle dimensioni: no, probabilmente non è mai assolutamente necessario, ma potrebbe essere il modo più semplice (ad esempio, alcuni byte di spazio di archiviazione per le dimensioni potrebbero evitare molti byte di codice per calcolarlo).

— Jerry Coffin,

@supercat: Riesco a vedere la logica della scelta della libreria C di Cherry, ma rendere le funzionalità del linguaggio "opzionali" sembra decisamente inutile a qualcuno che cerca di scrivere codice C multipiattaforma. In passato C era la scelta ovvia per la programmazione di sistemi vicini al metallo che poteva essere facilmente indirizzata a un altro compilatore e piattaforma hardware diversa. Ora, non è così ovvio.

— jxh

@supercat: bombardare lo stack non è univoco per VLA. Gli oggetti automatici di dimensioni eccessive o uno stack di chiamate di funzioni sfrenato avranno problemi simili. Se lo standard definisce un mezzo per rilevare guasti in questi casi, probabilmente funzionerebbe anche per VLA. In termini di facoltativo, rende più difficile discutere dell'utilizzo di nuove funzionalità C nel nuovo codice C in nuovi progetti che sono necessari per lavorare su più piattaforme utilizzando compilatori di più fornitori.

— jxh