perché entrambi indice [array] e array [indice] sono validi in C?

6

Ad esempio, considera:

int index = 3;
int array[4] = {0, 1, 2, 3};

quindi sia index[array] che array[index] sono espressioni valide, come *(index + array) e *(array + index) .

In array C perché è vero? array [5] == 5 [array] spiega come funziona. La mia domanda è: perché i designer linguistici hanno scelto di consentire questo? Perché non applicare semplicemente che index[array] non è valido, per chiarezza?

    
posta Cam 02.05.2012 - 19:42
fonte

6 risposte

12

Prima di tutto, sarebbe utile leggere il sviluppo del linguaggio C ottenere alcune informazioni su alcune delle peculiarità di C, in particolare quando si tratta di semantica dell'array (in pratica, biasimare BCPL e B per la maggior parte di esso).

Per quanto riguarda la domanda "[w] hy non solo impone che index[array] non sia valido, per chiarezza," cosa ti comprerebbe un assegno in cambio del costo di eseguirlo? Il modulo non appare quasi mai al di fuori del IOCCC , quindi non è come se fosse un grosso problema nel codice di produzione (rispetto all'uso, diciamo, gets o accessi di array non selezionati (che non consentono a i[a] di non di aiutare con), oppure < compilare il campo vuoto >). Non è un bug; non introduce alcun comportamento indefinito; non introduce buchi di sicurezza non già presenti con a[i] ; le uniche lamentele contro di essa sono di natura stilistica.

È come chiedere perché sia T *p che T* p siano validi; là è no "perché" al di là di ciò è un incidente della sintassi del linguaggio. Non c'è niente di intenzionale dietro ad entrambi, è solo una funzione di come funziona la grammatica. Lo stesso con a[i] e i[a] . I programmatori professionisti sono (di solito) adulti e non deliberatamente introducono confusione laddove non è garantito, quindi la maggior parte userà naturalmente a[i] .

Stai sostanzialmente cercando di evitare un problema che non esiste realmente.

    
risposta data 02.05.2012 - 23:48
fonte
5

La scelta di usare array[index] è stata probabilmente fatta per seguire la convenzione matematica e il precedente impostato per gli array da altri linguaggi come ALGOL, FORTRAN e BASIC (gli ultimi due usano parentesi invece di parentesi). Questa decisione rende l'operatore anormale perché è un operatore binario, ma richiede di inserire un token aggiuntivo dopo l'espressione della mano destra.

L'operatore avrebbe potuto facilmente essere un singolo carattere ( @ non è parlato in C, quindi chiamiamolo "operatore addizione puntatore"). Poiché, come sottolinea la risposta di David Thornley nella summenzionata domanda SO , l'aggiunta del puntatore è commutativa, a @ 5 e 5 @ a avere lo stesso senso (C precursore BCPL ha utilizzato ! per questo.)

In un certo senso è naturale guardare l'operatore dell'array comportarsi come una funzione, il che ha senso nel contesto dei linguaggi che fanno f(x) per chiamare una funzione e a(i) per accedere a un array. Poiché gli operatori in C non funzionano in questo modo, devi considerarlo come un operatore commutativo, binario con bagaglio.

    
risposta data 02.05.2012 - 20:42
fonte
2

Secondo James Curran la ragione di ciò era che quando C è stato sviluppato, i computer erano più lenti + avevano meno memoria, quindi tali controlli e ottimizzazioni non valevano il costo.

link

    
risposta data 02.05.2012 - 19:47
fonte
1

Potremmo non sapere mai per certo perché la funzione è stata permessa in primo luogo, ma è ovvio che rimane nella lingua oggi per compatibilità con le versioni precedenti della lingua. Non c'è alcun motivo ovvio e convincente per rimuoverlo, quindi non ha senso rompere gratuitamente il codice esistente.

    
risposta data 02.05.2012 - 20:02
fonte
1

È un po 'come chiedere perché le persone progetterebbero auto in grado di colpire i pedoni. Non lo fanno. Progettano le auto per fare ciò che i loro autisti dicono loro di fare. C è stato progettato con la pazza idea arcana che i programmatori siano responsabili dei propri programmi e, se scrivono qualcosa di stupido in un linguaggio di programmazione, è sotto la loro responsabilità. Decisioni di progettazione errate sul lato delle rimozione delle restrizioni del programmatore.

    
risposta data 02.05.2012 - 22:03
fonte
-6

Perché, come molte altre funzionalità di C, non è stato pensato. Dubito che qualcuno stia davvero pensando alla logica matematica dietro il recupero di immagini in memoria. A quanto pare, però, entrambe le operazioni producono la stessa matematica (in pratica).

E il signor Curran potrebbe dirlo, ma immagino che non abbia molto a che fare con il costo del calcolo. Potrei sbagliarmi comunque.

    
risposta data 02.05.2012 - 19:50
fonte

Leggi altre domande sui tag