Perché le matrici C non tengono traccia della loro lunghezza?

Qual è stato il ragionamento alla base della non memorizzazione esplicita della lunghezza di un array con un array in C?

Per come la vedo io, ci sono ragioni schiaccianti per farlo, ma non molti a supporto dello standard (C89). Per esempio:

1. La disponibilità della lunghezza in un buffer può impedire il sovraccarico del buffer.
2. Uno stile Java arr.lengthè chiaro ed evita al programmatore di mantenere molte ints nello stack se si occupa di più array
3. I parametri di funzione diventano più convincenti.

Ma forse la ragione più motivante, secondo me, è che di solito nessuno spazio viene salvato senza mantenere la lunghezza. Mi azzarderei a dire che la maggior parte degli usi degli array implica allocazione dinamica. È vero, ci possono essere alcuni casi in cui le persone usano un array allocato nello stack, ma questa è solo una chiamata di funzione *: lo stack può gestire 4 o 8 byte in più.

Poiché il gestore heap deve tenere traccia della dimensione del blocco libero utilizzata dall'array allocato in modo dinamico, perché non rendere utilizzabili tali informazioni (e aggiungere la regola aggiuntiva, verificata al momento della compilazione, che non si può manipolare esplicitamente la lunghezza a meno che non si vorrebbe piace spararsi al piede).

L'unica cosa che mi viene in mente sul lato opposto è che nessun inseguimento lunghezza può aver fatto compilatori più semplice, ma non che molto più semplice.

* Tecnicamente, si potrebbe scrivere una sorta di funzione ricorsiva con un array con memorizzazione automatica, e in questo caso (molto elaborato) l'archiviazione della lunghezza può effettivamente comportare un maggiore utilizzo dello spazio.

Le matrici C tengono traccia della loro lunghezza, poiché la lunghezza della matrice è una proprietà statica:

int xs[42];  /* a 42-element array */

Di solito non è possibile eseguire query su questa lunghezza, ma non è necessario perché è comunque statico: basta dichiarare una macro XS_LENGTHper la lunghezza e il gioco è fatto.

Il problema più importante è che gli array C si degradano implicitamente in puntatori, ad esempio quando vengono passati a una funzione. Questo ha un senso e consente alcuni trucchi di basso livello, ma perde le informazioni sulla lunghezza dell'array. Quindi una domanda migliore sarebbe perché C è stato progettato con questo implicito degrado dei puntatori.

Un'altra questione è che i puntatori non necessitano di archiviazione tranne l'indirizzo di memoria stesso. C ci consente di trasmettere numeri interi a puntatori, puntatori ad altri puntatori e di trattare i puntatori come se fossero matrici. Nel fare questo, C non è abbastanza folle da fabbricare una certa lunghezza dell'array, ma sembra fidarsi del motto di Spiderman: con grande potenza il programmatore si spera possa adempiere alla grande responsabilità di tenere traccia delle lunghezze e degli overflow.

Molto di ciò ha avuto a che fare con i computer disponibili al momento. Non solo il programma compilato doveva essere eseguito su un computer con risorse limitate, ma, forse ancora più importante, il compilatore stesso doveva essere eseguito su queste macchine. All'epoca Thompson sviluppò C, stava usando un PDP-7, con 8k di RAM. Le funzioni linguistiche complesse che non avevano un analogo immediato sul codice macchina effettivo non erano semplicemente incluse nella lingua.

Una lettura attenta della storia di C offre una maggiore comprensione di quanto sopra, ma non era interamente il risultato dei limiti della macchina che avevano:

Inoltre, il linguaggio (C) mostra un notevole potere nel descrivere concetti importanti, ad esempio vettori la cui lunghezza varia in fase di esecuzione, con solo alcune regole e convenzioni di base. ... È interessante confrontare l'approccio di C con quello di due lingue quasi contemporanee, Algol 68 e Pascal [Jensen 74]. Le matrici in Algol 68 hanno limiti fissi o sono "flessibili:" è necessario un considerevole meccanismo sia nella definizione della lingua che nei compilatori, per adattarsi alle matrici flessibili (e non tutti i compilatori le implementano completamente). L'originale Pascal aveva solo dimensioni fisse array e stringhe, e questo si è rivelato limitato [Kernighan 81].

Le matrici C sono intrinsecamente più potenti. L'aggiunta di limiti ad essi limita ciò per cui il programmatore può usarli. Tali restrizioni possono essere utili per i programmatori, ma necessariamente sono anche limitanti.

Ai tempi della creazione di C e 4 byte in più di spazio per ogni stringa, non importa quanto breve sarebbe stato un vero spreco!

C'è un altro problema: ricorda che C non è orientato agli oggetti, quindi se fai il prefisso lunghezza tutte le stringhe, dovrebbe essere definito come un tipo intrinseco del compilatore, non un char*. Se fosse un tipo speciale, non saresti in grado di confrontare una stringa con una stringa costante, ovvero:

String x = "hello";
if (strcmp(x, "hello") == 0) 
  exit;

dovrebbe avere particolari dettagli del compilatore per convertire quella stringa statica in una stringa o avere funzioni di stringa diverse per tenere conto del prefisso lunghezza.

Penso che alla fine, però, non hanno semplicemente scelto il prefisso di lunghezza a differenza di come dice Pascal.

In C, qualsiasi sottoinsieme contiguo di un array è anche un array e può essere utilizzato come tale. Questo vale sia per le operazioni di lettura che di scrittura. Questa proprietà non verrebbe mantenuta se la dimensione fosse archiviata in modo esplicito.

Il problema più grande di avere le matrici taggate con la loro lunghezza non è tanto lo spazio necessario per memorizzare quella lunghezza, né la domanda su come dovrebbe essere memorizzata (l'uso di un byte aggiuntivo per le matrici corte in genere non sarebbe discutibile, né l'utilizzo di quattro byte extra per array lunghi, ma potrebbe essere l'utilizzo di quattro byte anche per array brevi). Un problema molto più grande è che dato un codice come:

void ClearTwoElements(int *ptr)
{
  ptr[-2] = 0;
  ptr[2] = 0;
}
void blah(void)
{
  static int foo[10] = {1,2,3,4,5,6,7,8,9,10};
  ClearTwoElements(foo+2);
  ClearTwoElements(foo+7);
  ClearTwoElements(foo+1);
  ClearTwoElements(foo+8);
}

l'unico modo in cui il codice sarebbe in grado di accettare la prima chiamata ClearTwoElementsma di rifiutare la seconda sarebbe che il ClearTwoElementsmetodo riceva informazioni sufficienti per sapere che in ogni caso stava ricevendo un riferimento a una parte dell'array foooltre a sapere quale parte. Questo in genere raddoppierebbe il costo del passaggio dei parametri del puntatore. Inoltre, se ogni array fosse preceduto da un puntatore a un indirizzo appena oltre la fine (il formato più efficiente per la convalida), il codice ottimizzato per ClearTwoElementsdiventerebbe probabilmente qualcosa del tipo:

void ClearTwoElements(int *ptr)
{
  int* array_end = ARRAY_END(ptr);
  if ((array_end - ARRAY_BASE(ptr)) < 10 ||
      (ARRAY_BASE(ptr)+4) <= ADDRESS(ptr) ||          
      (array_end - 4) < ADDRESS(ptr)))
    trap();
  *(ADDRESS(ptr) - 4) = 0;
  *(ADDRESS(ptr) + 4) = 0;
}

Si noti che un chiamante di metodo potrebbe, in generale, passare perfettamente un puntatore all'inizio dell'array o l'ultimo elemento a un metodo; solo se il metodo tenta di accedere ad elementi che escono dall'array pass-in tali puntatori potrebbero causare problemi. Di conseguenza, un metodo chiamato dovrebbe prima assicurarsi che l'array fosse abbastanza grande da consentire all'aritmetica del puntatore di convalidare i suoi argomenti non andrà oltre i limiti, quindi eseguire alcuni calcoli del puntatore per convalidare gli argomenti. Il tempo impiegato in tale convalida probabilmente supererebbe il costo speso per qualsiasi lavoro reale. Inoltre, il metodo potrebbe probabilmente essere più efficiente se fosse scritto e chiamato:

void ClearTwoElements(int arr[], int index)
{
  arr[index-2] = 0;
  arr[index+2] = 0;
}
void blah(void)
{
  static int foo[10] = {1,2,3,4,5,6,7,8,9,10};
  ClearTwoElements(foo,2);
  ClearTwoElements(foo,7);
  ClearTwoElements(foo,1);
  ClearTwoElements(foo,8);
}

Il concetto di un tipo che combina qualcosa per identificare un oggetto con qualcosa per identificare un suo pezzo è valido. Un puntatore in stile C è più veloce, tuttavia, se non è necessario eseguire la convalida.

Una delle differenze fondamentali tra C e la maggior parte delle altre lingue di terza generazione, e tutte le lingue più recenti di cui sono a conoscenza, è che C non è stato progettato per rendere la vita più facile o più sicura per il programmatore. È stato progettato con l'aspettativa che il programmatore sapesse cosa stavano facendo e voleva fare esattamente e solo quello. Non fa nulla "dietro le quinte", quindi non si ottengono sorprese. Anche l'ottimizzazione a livello di compilatore è facoltativa (a meno che non si utilizzi un compilatore Microsoft).

Se un programmatore vuole scrivere limiti controllando nel proprio codice, C rende abbastanza semplice farlo, ma il programmatore deve scegliere di pagare il prezzo corrispondente in termini di spazio, complessità e prestazioni. Anche se non lo uso con rabbia da molti anni, lo uso ancora quando insegno alla programmazione per comprendere il concetto di processo decisionale basato sui vincoli. Fondamentalmente, ciò significa che puoi scegliere di fare tutto quello che vuoi, ma ogni decisione che prendi ha un prezzo di cui devi essere consapevole. Questo diventa ancora più importante quando inizi a dire agli altri cosa vuoi che facciano i loro programmi.

Risposta breve:

Poiché C è un linguaggio di programmazione di basso livello , si aspetta che tu ti occupi di questi problemi da solo, ma questo aggiunge una maggiore flessibilità esattamente nel modo in cui lo implementi.

C ha un concetto in fase di compilazione di un array che viene inizializzato con una lunghezza ma in fase di esecuzione l'intera cosa viene semplicemente memorizzata come un singolo puntatore all'inizio dei dati. Se si desidera passare la lunghezza dell'array a una funzione insieme all'array, lo si fa da soli:

retval = my_func(my_array, my_array_length);

Oppure potresti usare una struttura con un puntatore e una lunghezza o qualsiasi altra soluzione.

Un linguaggio di livello superiore lo farebbe per te come parte del suo tipo di array. In C ti viene data la responsabilità di farlo da solo, ma anche la flessibilità di scegliere come farlo. E se tutto il codice che stai scrivendo conosce già la lunghezza dell'array, non è necessario passare la lunghezza come variabile.

L'ovvio svantaggio è che senza limiti intrinseci che controllano gli array passati come puntatori è possibile creare un codice pericoloso, ma questa è la natura dei linguaggi di sistema / livello basso e il compromesso che danno.

Il problema dell'archiviazione aggiuntiva è un problema, ma a mio avviso un problema minore. Dopotutto, la maggior parte delle volte dovrai comunque tenere traccia della lunghezza, anche se Amon ha sottolineato che spesso può essere tracciato staticamente.

Un problema più grande è dove memorizzare la lunghezza e quanto tempo per farlo. Non esiste un posto che funzioni in tutte le situazioni. Si potrebbe dire semplicemente di archiviare la lunghezza nella memoria appena prima dei dati. Cosa succede se l'array non punta alla memoria, ma qualcosa di simile a un buffer UART?

Lasciare fuori la lunghezza consente al programmatore di creare le proprie astrazioni per la situazione appropriata e ci sono molte librerie già pronte disponibili per il caso generale. La vera domanda è: perché quelle astrazioni non vengono utilizzate in applicazioni sensibili alla sicurezza?

Dallo sviluppo del linguaggio C :

Le strutture, a quanto pare, dovrebbero mappare in modo intuitivo sulla memoria della macchina, ma in una struttura che contiene un array, non c'era un buon posto per riporre il puntatore contenente la base dell'array, né un modo conveniente per organizzare che fosse inizializzato. Ad esempio, le voci di directory dei primi sistemi Unix potrebbero essere descritte in C come

struct {
    int inumber;
    char    name[14];
};

Volevo che la struttura non solo caratterizzasse un oggetto astratto, ma descrivesse anche una raccolta di bit che potevano essere letti da una directory. Dove potrebbe il compilatore nascondere il puntatore namerichiesto dalla semantica? Anche se le strutture fossero pensate in modo più astratto e lo spazio per i puntatori potesse essere nascosto in qualche modo, come potrei gestire il problema tecnico di inizializzare correttamente questi puntatori durante l'allocazione di un oggetto complicato, forse uno che specificava strutture con array contenenti strutture a profondità arbitraria?

La soluzione ha costituito il salto cruciale nella catena evolutiva tra BCPL senza tipizzazione e tipizzata C. Ha eliminato la materializzazione del puntatore in memoria e ha invece causato la creazione del puntatore quando il nome dell'array è menzionato in un'espressione. La regola, che sopravvive nella C odierna, è che i valori di tipo array vengono convertiti, quando compaiono in espressioni, in puntatori al primo degli oggetti che compongono l'array.

Quel passaggio affronta il motivo per cui le espressioni di array decadono in puntatori nella maggior parte dei casi, ma lo stesso ragionamento si applica al motivo per cui la lunghezza dell'array non è memorizzata con l'array stesso; se vuoi un mapping uno a uno tra la definizione del tipo e la sua rappresentazione in memoria (come ha fatto Ritchie), allora non c'è un buon posto per archiviare quei metadati.

Inoltre, pensa alle matrici multidimensionali; dove memorizzeresti i metadati di lunghezza per ogni dimensione in modo tale da poter ancora percorrere l'array con qualcosa del genere

T *p = &a[0][0];

for ( size_t i = 0; i < rows; i++ )
  for ( size_t j = 0; j < cols; j++ )
    do_something_with( *p++ );

La domanda presuppone che ci siano array in C. Non ce ne sono. Le cose che si chiamano array sono solo uno zucchero sintattico per operazioni su sequenze continue di dati e aritmetica dei puntatori.

Il codice seguente copia alcuni dati da src a dst in blocchi di dimensioni int non sapendo che in realtà è una stringa di caratteri.

char src[] = "Hello, world";
char dst[1024];
int *my_array = src; /* What? Compiler warning, but the code is valid. */
int *other_array = dst;
int i;
for (i = 0; i <= sizeof(src)/sizeof(int); i++)
    other_array[i] = my_array[i]; /* Oh well, we've copied some extra bytes */
printf("%s\n", dst);

Perché C è così semplificato da non avere array adeguati? Non conosco la risposta corretta a questa nuova domanda. Ma alcune persone spesso affermano che C è solo (in qualche modo) più leggibile e assemblatore portatile.