Perché gli array a lunghezza variabile non fanno parte dello standard C ++?

Non ho usato molto C negli ultimi anni. Quando ho letto questa domanda oggi mi sono imbattuto in una sintassi C che non conoscevo.

Apparentemente in C99 è valida la seguente sintassi:

void foo(int n) {
    int values[n]; //Declare a variable length array
}

Questa sembra una funzionalità piuttosto utile. Si è mai discusso dell'aggiunta allo standard C ++ e, in caso affermativo, perché è stato omesso?

Alcuni potenziali motivi:

• Peloso per i fornitori di compilatori da implementare
• Incompatibile con qualche altra parte dello standard
• La funzionalità può essere emulata con altri costrutti C ++

Lo standard C ++ afferma che la dimensione dell'array deve essere un'espressione costante (8.3.4.1).

Sì, ovviamente mi rendo conto che nell'esempio giocattolo si potrebbe usare std::vector<int> values(m);, ma questo alloca memoria dall'heap e non dallo stack. E se voglio un array multidimensionale come:

void foo(int x, int y, int z) {
    int values[x][y][z]; // Declare a variable length array
}

la vectorversione diventa piuttosto maldestra:

void foo(int x, int y, int z) {
    vector< vector< vector<int> > > values( /* Really painful expression here. */);
}

Anche le sezioni, le righe e le colonne saranno potenzialmente distribuite su tutta la memoria.

Guardando la discussione comp.std.c++è chiaro che questa domanda è piuttosto controversa con alcuni nomi molto pesanti su entrambi i lati dell'argomento. Non è certo ovvio che a std::vectorsia sempre una soluzione migliore.

Recentemente è stata avviata una discussione al riguardo in usenet: perché nessun VLA in C ++ 0x .

Sono d'accordo con quelle persone che sembrano concordare sul fatto che dover creare un potenziale array di grandi dimensioni nello stack, che di solito ha solo poco spazio disponibile, non è buono. L'argomento è, se si conosce in anticipo la dimensione, è possibile utilizzare un array statico. E se non conosci in anticipo le dimensioni, scriverai un codice non sicuro.

I VLA C99 potrebbero offrire un piccolo vantaggio nel poter creare piccoli array senza sprecare spazio o chiamare costruttori per elementi inutilizzati, ma introdurranno modifiche piuttosto grandi al sistema dei tipi (è necessario essere in grado di specificare i tipi in base ai valori di runtime - questo non esiste ancora nell'attuale C ++, ad eccezione newdegli specificatori di tipi di operatore, ma sono trattati in modo speciale, in modo che il tempo di esecuzione non sfugga all'ambito newdell'operatore).

Puoi usarlo std::vector, ma non è esattamente lo stesso, in quanto utilizza la memoria dinamica e farla utilizzare il proprio allocatore di stack non è esattamente facile (anche l'allineamento è un problema). Inoltre, non risolve lo stesso problema, poiché un vettore è un contenitore ridimensionabile, mentre i VLA sono di dimensioni fisse. La proposta di array dinamico C ++ ha lo scopo di introdurre una soluzione basata su libreria, in alternativa a un VLA basato sul linguaggio. Tuttavia, non farà parte del C ++ 0x, per quanto ne so.

(Background: ho una certa esperienza nell'implementazione di compilatori C e C ++.)

Le matrici a lunghezza variabile in C99 erano sostanzialmente un passo falso. Per supportare i VLA, C99 doveva fare le seguenti concessioni al buon senso:

• sizeof xnon è più sempre una costante di compilazione; il compilatore deve talvolta generare codice per valutare sizeofun'espressione in fase di esecuzione.

• Permettendo VLA bidimensionali ( int A[x][y]) necessaria una nuova sintassi per le funzioni che accettano 2D VLA come parametri dichiara: void foo(int n, int A[][*]).

• Ancora meno importante nel mondo C ++, ma estremamente importante per il pubblico target di C di programmatori di sistemi embedded, dichiarare un VLA significa tagliare un pezzo arbitrariamente grande del proprio stack. Questo è uno stack overflow e crash garantito . (Ogni volta che si dichiara int A[n], si sta implicitamente affermando che avete 2GB di stack di riserva. Dopo tutto, se si sa " nè sicuramente inferiore a 1000 qui", quindi si sarebbe solo dichiarare int A[1000]. Sostituendo il numero intero a 32 bit nper 1000è un'ammissione che non hai idea di quale dovrebbe essere il comportamento del tuo programma.)

Bene, passiamo ora a parlare di C ++. In C ++, abbiamo la stessa forte distinzione tra "sistema di tipo" e "sistema di valori" che fa C89 ... ma abbiamo davvero iniziato a fare affidamento su di esso in modi che C non ha. Per esempio:

template<typename T> struct S { ... };
int A[n];
S<decltype(A)> s;  // equivalently, S<int[n]> s;

Se nnon fosse una costante di compilazione (cioè se Afosse di tipo variamente modificato), quale sarebbe il tipo di S? Sarebbe S's tipo anche essere determinata solo in fase di esecuzione?

Che dire di questo:

template<typename T> bool myfunc(T& t1, T& t2) { ... };
int A1[n1], A2[n2];
myfunc(A1, A2);

Il compilatore deve generare il codice per alcune istanze di myfunc. Come dovrebbe essere quel codice? Come possiamo generare staticamente quel codice, se non conosciamo il tipo di A1al momento della compilazione?

Peggio ancora, cosa succede se si scopre in fase di esecuzione che n1 != n2, in modo che !std::is_same<decltype(A1), decltype(A2)>()? In tal caso, la chiamata a myfunc non dovrebbe nemmeno essere compilata , perché la deduzione del tipo di modello non dovrebbe riuscire! Come potremmo eventualmente emulare quel comportamento in fase di esecuzione?

Fondamentalmente, C ++ si sta muovendo nella direzione di spingere sempre più decisioni in fase di compilazione : generazione di codice modello, constexprvalutazione delle funzioni e così via. Nel frattempo, C99 era impegnato a spingere le decisioni tradizionalmente in fase di compilazione (ad es. sizeof) Nel runtime . Con questo in mente, ha davvero senso spendere qualche sforzo nel tentativo di integrare i VLA in stile C99 in C ++?

Come ogni altro risponditore ha già sottolineato, C ++ fornisce molti meccanismi di allocazione dell'heap ( std::unique_ptr<int[]> A = new int[n];o std::vector<int> A(n);essendo quelli ovvi) quando si vuole davvero trasmettere l'idea "Non ho idea di quanta RAM potrei avere bisogno". E C ++ fornisce un elegante modello di gestione delle eccezioni per affrontare l'inevitabile situazione in cui la quantità di RAM necessaria è maggiore della quantità di RAM che hai. Ma spero che questa risposta ti dia una buona idea del perché i VLA in stile C99 non si adattano bene al C ++ e non si adattano nemmeno al C99. ;)

Per ulteriori informazioni sull'argomento, vedere N3810 "Alternative per estensioni di array" , articolo di Bjarne Stroustrup dell'ottobre 2013 sui VLA. Il POV di Bjarne è molto diverso dal mio; N3810 si concentra maggiormente sulla ricerca di una buona sintassi ish C ++ per le cose e sullo scoraggiamento dell'uso di array grezzi in C ++, mentre mi sono concentrato maggiormente sulle implicazioni per la metaprogrammazione e il sistema dei tipi. Non so se considera risolte, risolvibili o semplicemente poco interessanti le implicazioni relative alla metaprogrammazione / tipi di sistema.

Un buon post sul blog che colpisce molti di questi stessi punti è "Uso legittimo di array a lunghezza variabile" (Chris Wellons, 27-10-2019).

È sempre possibile utilizzare alloca () per allocare memoria nello stack in fase di esecuzione, se si desidera:

void foo (int n)
{
    int *values = (int *)alloca(sizeof(int) * n);
}

L'allocazione nello stack implica che verrà automaticamente liberato quando lo stack si svolge.

Nota rapida: come menzionato nella pagina man di Mac OS X per alloca (3), "La funzione alloca () dipende dalla macchina e dal compilatore; il suo uso è sconsigliato." Solo così lo sai.

Nel mio lavoro, mi sono reso conto che ogni volta che volevo qualcosa come array automatici di lunghezza variabile o alloca (), non mi importava davvero che la memoria fosse fisicamente situata nello stack della CPU, solo che proveniva da un qualche allocatore di stack che non ha comportato viaggi lenti nell'heap generale. Quindi ho un oggetto per thread che possiede un po 'di memoria da cui può spingere / pop buffer di dimensioni variabili. Su alcune piattaforme, permetto che questo cresca tramite mmu. Altre piattaforme hanno una dimensione fissa (di solito accompagnata da uno stack di CPU di dimensioni fisse, anche perché non mmu). Una piattaforma con cui lavoro (una console di gioco portatile) ha comunque un piccolo stack di CPU prezioso perché risiede in una memoria scarsa e veloce.

Non sto dicendo che non è mai necessario spingere buffer di dimensioni variabili nello stack della cpu. Onestamente sono stato sorpreso quando ho scoperto che questo non era standard, in quanto sembra certamente che il concetto si adatti abbastanza bene alla lingua. Per me, tuttavia, i requisiti "dimensione variabile" e "devono trovarsi fisicamente nello stack della cpu" non sono mai stati messi insieme. Si trattava di velocità, quindi ho creato il mio tipo di "stack parallelo per buffer di dati".

Esistono situazioni in cui l'allocazione della memoria dell'heap è molto costosa rispetto alle operazioni eseguite. Un esempio è la matematica a matrice. Se lavori con matrici di dimensioni ridotte, inserisci da 5 a 10 elementi e fai molte aritmetiche il sovraccarico malloc sarà davvero significativo. Allo stesso tempo, rendere le dimensioni una costante di tempo di compilazione sembra molto dispendioso e poco flessibile.

Penso che il C ++ sia così insicuro in sé che l'argomento di "provare a non aggiungere più funzionalità non sicure" non è molto forte. D'altra parte, poiché C ++ è probabilmente il linguaggio di programmazione più efficiente in termini di runtime che lo rende sempre più utile, sono sempre utili: le persone che scrivono programmi critici per le prestazioni useranno in larga misura C ++ e hanno bisogno di quante più prestazioni possibili. Spostare le cose dall'heap allo stack è una di queste possibilità. Ridurre il numero di blocchi heap è un altro. Consentire VLA come membri oggetto sarebbe un modo per raggiungere questo obiettivo. Sto lavorando a un suggerimento del genere. È un po 'complicato da implementare, è vero, ma sembra abbastanza fattibile.

Sembra che sarà disponibile in C ++ 14:

https://en.wikipedia.org/wiki/C%2B%2B14#Runtime-sized_one_dimensional_arrays

Aggiornamento: non è diventato C ++ 14.

Questo è stato considerato per l'inclusione in C ++ / 1x, ma è stato abbandonato (questa è una correzione a ciò che ho detto prima).

Sarebbe comunque meno utile in C ++ poiché dobbiamo già std::vectorricoprire questo ruolo.

Usa std :: vector per questo. Per esempio:

std::vector<int> values;
values.resize(n);

La memoria verrà allocata sull'heap, ma ciò comporta solo un piccolo inconveniente delle prestazioni. Inoltre, è consigliabile non allocare grandi datablock nello stack, poiché è piuttosto limitato nelle dimensioni.

C99 consente VLA. E pone alcune restrizioni su come dichiarare VLA. Per i dettagli, fare riferimento a 6.7.5.2 della norma. C ++ non consente VLA. Ma g ++ lo consente.

Le matrici come questa fanno parte del C99, ma non fanno parte del C ++ standard. come altri hanno già detto, un vettore è sempre una soluzione molto migliore, motivo per cui gli array di dimensioni variabili non si trovano nello standatrd C ++ (o nello standard C ++ 0x proposto).

A proposito, per domande sul "perché" lo standard C ++ è così com'è, il newsgroup Usenet moderato comp.std.c ++ è il posto dove andare.

Se si conosce il valore al momento della compilazione, è possibile effettuare le seguenti operazioni:

template <int X>
void foo(void)
{
   int values[X];

}

Modifica: è possibile creare un vettore che utilizza un allocatore di stack (alloca), poiché l'allocatore è un parametro modello.

Ho una soluzione che ha funzionato davvero per me. Non volevo allocare memoria a causa della frammentazione di una routine che doveva essere eseguita molte volte. La risposta è estremamente pericolosa, quindi usala a tuo rischio e pericolo, ma sfrutta l'assemblaggio per riservare spazio sulla pila. Il mio esempio di seguito usa una matrice di caratteri (ovviamente altre variabili di dimensioni richiederebbero più memoria).

void varTest(int iSz)
{
    char *varArray;
    __asm {
        sub esp, iSz       // Create space on the stack for the variable array here
        mov varArray, esp  // save the end of it to our pointer
    }

    // Use the array called varArray here...  

    __asm {
        add esp, iSz       // Variable array is no longer accessible after this point
    } 
}

I pericoli qui sono molti, ma ne spiegherò alcuni: 1. Cambiare la dimensione della variabile a metà strada ucciderebbe la posizione dello stack 2. Superare i limiti dell'array distruggerebbe altre variabili e il possibile codice 3. Questo non funziona a 64 bit build ... necessita di un assembly diverso per quello (ma una macro potrebbe risolvere quel problema). 4. Specifico per il compilatore (potrebbe avere difficoltà a spostarsi tra i compilatori). Non ci ho provato, quindi davvero non lo so.