Perché abbiamo l'incremento postfix?

Disclaimer : conosco perfettamente la semantica del prefisso e l'incremento postfisso. Quindi per favore non spiegarmi come funzionano.

Leggendo le domande sullo overflow dello stack, non posso fare a meno di notare che i programmatori vengono continuamente confusi dall'operatore di incremento postfix. Da ciò nasce la seguente domanda: esiste qualche caso d'uso in cui l'incremento postfix offre un reale vantaggio in termini di qualità del codice?

Vorrei chiarire la mia domanda con un esempio. Ecco un'implementazione super-concisa di strcpy:

while (*dst++ = *src++);

Ma questo non è esattamente il codice più auto-documentante nel mio libro (e produce due fastidiosi avvertimenti sui compilatori sani di mente). Quindi cosa c'è che non va nella seguente alternativa?

while (*dst = *src)
{
    ++src;
    ++dst;
}

Possiamo quindi eliminare l'incarico confuso nella condizione e ottenere un codice completamente privo di avvisi:

while (*src != '\0')
{
    *dst = *src;
    ++src;
    ++dst;
}
*dst = '\0';

(Sì, lo so, srce dstavranno valori finali diversi in queste soluzioni alternative, ma poiché strcpyritorna immediatamente dopo il ciclo, in questo caso non importa.)

Sembra che lo scopo dell'incremento postfix sia di rendere il codice il più conciso possibile. Semplicemente non riesco a vedere come questo è qualcosa per cui dovremmo lottare. Se inizialmente si trattava di prestazioni, è ancora rilevante oggi?

Mentre una volta aveva alcune implicazioni sulle prestazioni, penso che la vera ragione sia esprimere il tuo intento in modo pulito. La vera domanda è se qualcosa while (*d++=*s++);esprime chiaramente o meno l'intento. IMO, lo fa, e trovo le alternative che offri meno chiare, ma ciò potrebbe (facilmente) essere il risultato di aver passato decenni ad abituarsi al modo in cui le cose vengono fatte. Avere imparato C da K&R (perché all'epoca non c'erano quasi altri libri su C) probabilmente aiuta anche.

In una certa misura, è vero che la terseness è stata valutata in misura molto maggiore nel codice precedente. Personalmente, penso che questa sia stata in gran parte una buona cosa: capire alcune righe di codice è di solito abbastanza banale; ciò che è difficile è comprendere grandi blocchi di codice. Test e studi hanno dimostrato ripetutamente che l'adattamento di tutto il codice sullo schermo in una sola volta è un fattore importante nella comprensione del codice. Man mano che le schermate si espandono, questo sembra rimanere vero, quindi mantenere il codice (ragionevolmente) conciso rimane prezioso.

Ovviamente è possibile esagerare, ma non credo che lo sia. In particolare, penso che esagerare quando la comprensione di una singola riga di codice diventa estremamente difficile o richiede tempo, in particolare quando la comprensione di un numero minore di righe di codice richiede più sforzo rispetto alla comprensione di più righe. Questo è frequente in Lisp e APL, ma non sembra (almeno per me) essere il caso qui.

Sono meno preoccupato per gli avvisi del compilatore - è la mia esperienza che molti compilatori emettono avvisi assolutamente ridicoli su una base abbastanza regolare. Mentre certamente penso che le persone dovrebbero capire il loro codice (e tutti gli avvisi che potrebbe produrre), il codice decente che si verifica per attivare un avviso in alcuni compilatori non è necessariamente sbagliato. Certo, i principianti non sanno sempre cosa possono tranquillamente ignorare, ma non restiamo per sempre principianti e non abbiamo bisogno di programmare come noi.

È, err, era, una cosa hardware

Interessante da notare. L'incremento di Postfix è probabilmente lì per una serie di ragioni perfettamente valide, ma come molte cose in C, la sua popolarità può essere fatta risalire all'origine della lingua.

Sebbene C sia stato sviluppato su una varietà di macchine precoci e sottodimensionate, C e Unix hanno colpito per la prima volta il relativo big-time con i modelli di PDP-11 gestiti dalla memoria. Questi erano computer relativamente importanti ai loro tempi e Unix era di gran lunga migliore - esponenzialmente migliore - degli altri 7 sistemi operativi scadenti disponibili per -11.

E, succede così, che sul PDP-11,

*--p

e

*p++

... sono stati implementati nell'hardware come modalità di indirizzamento. (Inoltre *p, ma nessun'altra combinazione.) Su quei primi computer, tutti a meno di 0,001 GHz, il salvataggio di un'istruzione o due in un ciclo deve essere quasi stato un attesa al secondo o attendere un minuto o uscire per -grassa differenza. Questo non parla precisamente del postincremento, ma un ciclo con postincremento puntatore avrebbe potuto essere molto meglio dell'indicizzazione di allora.

Di conseguenza, il design si modella perché i modi di dire C sono diventati macro mentali.

È qualcosa come dichiarare le variabili subito dopo un {... non da quando C89 era attuale, questo è stato un requisito, ma ora è un modello di codice.

Aggiornamento: ovviamente, il motivo principale *p++è nella lingua perché è esattamente ciò che si vuole fare così spesso. La popolarità del modello di codice fu rafforzata dall'hardware popolare che arrivò e corrispondeva al modello già esistente di un linguaggio progettato leggermente prima dell'arrivo del PDP-11.

In questi giorni non fa alcuna differenza quale modello usi o se usi l'indicizzazione e di solito programmiamo a un livello superiore, ma deve aver avuto molta importanza su quelle macchine a 0,001 GHz e usare qualsiasi cosa diversa da *--xo ti *x++avrebbe significato non hai "preso" il PDP-11 e potresti avere persone che ti vengono incontro e che dicono "lo sapevi che ..." :-) :-)

Il prefisso, il postfisso --e gli ++operatori furono introdotti nel linguaggio B (il predecessore di C) da Ken Thompson - e no, non furono ispirati dal PDP-11, che all'epoca non esisteva.

Citando da "Lo sviluppo del linguaggio C" di Dennis Ritchie :

Thompson ha fatto un ulteriore passo avanti inventando il ++e--operatori, che incrementano o diminuiscono; la loro posizione prefisso o postfisso determina se l'alterazione si verifica prima o dopo aver notato il valore dell'operando. Non erano nelle prime versioni di B, ma apparvero lungo la strada. Le persone spesso immaginano di essere state create per utilizzare le modalità di indirizzo di auto-incremento e decremento automatico fornite dal DEC PDP-11 su cui C e Unix sono diventati popolari per la prima volta. Questo è storicamente impossibile, dal momento che non c'era PDP-11 quando B è stato sviluppato. Il PDP-7, tuttavia, aveva alcune celle di memoria "auto-incrementate", con la proprietà che un riferimento di memoria indiretta attraverso di esse incrementava la cella. Questa caratteristica suggeriva probabilmente tali operatori a Thompson; la generalizzazione per renderli sia prefissi che postfissi era la sua. Infatti,++xera più piccolo di quello di x=x+1.

La ragione ovvia dell'esistenza dell'operatore di postincremento è che non è necessario scrivere espressioni simili (++x,x-1)o (x+=1,x-1)dappertutto o separare inutilmente dichiarazioni banali con effetti collaterali di facile comprensione in più istruzioni. Ecco alcuni esempi:

while (*s) x+=*s++-'0';

if (x) *s++='.';

Ogni volta che leggere o scrivere una stringa in avanti, il postincremento e non il preincremento, è quasi sempre un'operazione naturale. Non ho quasi mai incontrato gli usi del mondo reale per il preincremento, e l'unico uso principale che ho trovato per il pre-incremento è la conversione di numeri in stringhe (perché i sistemi di scrittura umana scrivono numeri al contrario).

Modifica: In realtà non sarebbe così brutto; invece di (++x,x-1)te, ovviamente, puoi usare ++x-1o (x+=1)-1. È ancora x++più leggibile.

Il PDP-11 offriva operazioni di post-incremento e pre-decremento nel set di istruzioni. Ora queste non erano istruzioni. Erano modificatori di istruzioni che ti permettevano di specificare che volevi il valore di un registro prima che fosse incrementato o dopo che fosse diminuito.

Ecco un passaggio per la copia di parole nel linguaggio macchina:

movw (r1)++,(r2)++

che spostava una parola da una posizione all'altra, indicata dai registri, e i registri sarebbero pronti a farlo di nuovo.

Poiché C è stato sviluppato e per il PDP-11, molti concetti utili hanno trovato la loro strada in C. C era inteso come un utile sostituto del linguaggio assemblatore. Sono stati aggiunti pre-incremento e post-decremento per simmetria.

Dubito che sia mai stato davvero necessario. Per quanto ne so, non si compila in qualcosa di più compatto sulla maggior parte delle piattaforme rispetto all'utilizzo del pre-incremento come hai fatto tu, nel ciclo. Era solo che al momento della creazione, la terseness del codice era più importante della chiarezza del codice.

Ciò non vuol dire che la chiarezza del codice non sia (o non fosse) importante, ma quando si digitava su un modem a basso baud (tutto ciò che si misura in baud è lento) in cui ogni sequenza di tasti doveva farcela il mainframe e quindi riecheggiare di nuovo un byte alla volta con un singolo bit utilizzato come controllo di parità, non è stato necessario digitare molto.

Questo è un po 'come il & e | operatore con precedenza inferiore a ==

È stato progettato con le migliori intenzioni (una versione non in corto circuito di && e ||), ma ora confonde i programmatori ogni giorno e probabilmente non cambierà mai.

Comunque, questa è solo una risposta in quanto penso che non ci sia una buona risposta alla tua domanda, ma probabilmente sarò smentito da un programmatore più guru di I.

--MODIFICARE--

Vorrei sottolineare che io trovo avendo entrambi incredibilmente utile, sto solo sottolineando che non cambierà se qualcuno piaccia o no.

Mi piace il postfix aperator quando ho a che fare con i puntatori (indipendentemente dal fatto che li dereferenzi o meno) perché

p++

legge più naturalmente come "passa al punto successivo" rispetto all'equivalente

p += 1

che sicuramente deve confondere i principianti la prima volta che lo vedono usato con un puntatore dove sizeof (* p)! = 1.

Sei sicuro di affermare correttamente il problema della confusione? Non è ciò che confonde i principianti il ​​fatto che l'operatore postfix ++ abbia una precedenza maggiore rispetto all'operatore dereference * in modo che

*p++

analizza come

*(p++)

e non

(*p)++

come qualcuno potrebbe aspettarsi?

(Pensi che sia male? Vedi la lettura delle dichiarazioni C. )

Tra gli elementi sottili di una buona programmazione ci sono la localizzazione e il minimalismo :

• mettere le variabili in un ambito di utilizzo minimo
• usando const quando non è richiesto l'accesso in scrittura
• eccetera.

Nello stesso spirito, x++può essere visto come un modo per localizzare un riferimento al valore corrente di xmentre indica immediatamente che hai - almeno per ora - finito con quel valore e vuoi passare al successivo (valido se xè un into un puntatore o iteratore). Con un po 'di immaginazione, potresti paragonare questo a lasciare il vecchio valore / posizione di x"fuori campo" immediatamente dopo che non è più necessario e passare al nuovo valore. Il punto preciso in cui è possibile tale transizione è evidenziato dal postfisso++ . L'implicazione che questo è probabilmente l'uso finale del "vecchio" xpuò essere una preziosa visione dell'algoritmo, aiutando il programmatore mentre scansionano il codice circostante. Certo, il postfisso++ può mettere il programmatore alla ricerca di usi del nuovo valore, che può essere o meno buono a seconda di quando quel nuovo valore è effettivamente necessario, quindi è un aspetto dell '"arte" o "mestiere" della programmazione per determinare cosa c'è di più utile nelle circostanze.

Mentre molti principianti possono essere confusi da una caratteristica, vale la pena bilanciarlo con i vantaggi a lungo termine: i principianti non rimangono principianti a lungo.

Wow, molte risposte non del tutto esatte (se posso essere così audace), e per favore perdonami se sto sottolineando l'ovvio, in particolare alla luce del tuo commento per non sottolineare la semantica, ma l'ovvio (dal punto di vista di Stroustrup, suppongo) non sembra ancora essere stato pubblicato! :)

Postfix x++produce un temporaneo che viene passato "verso l'alto" nell'espressione, mentre la variabile xviene successivamente incrementata.

Il prefisso ++xnon produce un oggetto temporaneo, ma incrementa 'x' e passa il risultato all'espressione.

Il valore è convenienza, per chi conosce l'operatore.

Per esempio:

int x = 1;
foo(x++); // == foo(1)
// x == 2: true

x = 1;
foo(++x); // == foo(2)
// x == 2: true

Naturalmente, i risultati di questo esempio possono essere prodotti da un altro codice equivalente (e forse meno obliquo).

Quindi perché abbiamo l'operatore postfix? Immagino perché sia ​​un linguaggio persistente, nonostante la confusione che ovviamente crea. È un costrutto legacy che una volta era percepito avere valore, anche se non sono sicuro che il valore percepito fosse tanto per le prestazioni quanto per la convenienza. Quella convenienza non è andata persa, ma penso che sia aumentato l'apprezzamento della leggibilità, con il risultato di mettere in discussione lo scopo dell'operatore.

Abbiamo più bisogno dell'operatore postfix? Probabilmente no. Il suo risultato è confuso e crea una barriera alla comprensibilità. Alcuni bravi programmatori sapranno immediatamente dove trovarlo utile, spesso in luoghi in cui ha una bellezza particolarmente "PERL-esque". Il costo di quella bellezza è leggibilità.

Concordo sul fatto che il codice esplicito abbia vantaggi rispetto a terseness, in leggibilità, comprensibilità e manutenibilità. Buoni designer e manager lo vogliono.

Tuttavia, c'è una certa bellezza che alcuni programmatori riconoscono che li incoraggia a produrre codice con cose puramente per una bella semplicità - come l'operatore postfix - quale codice che altrimenti non avrebbero mai pensato - o trovato stimolante intellettualmente. C'è qualcosa che lo rende più bello, se non più desiderabile, nonostante la devozione.

In altre parole, alcune persone trovano while (*dst++ = *src++);semplicemente una soluzione più bella, qualcosa che toglie il respiro con la sua semplicità, proprio come se fosse un pennello su tela. Il fatto che tu sia costretto a capire la lingua per apprezzare la bellezza non fa che aumentare la sua magnificenza.

Diamo un'occhiata alla giustificazione originale di Kernighan & Ritchie (K&R originali pagina 42 e 43):

Gli aspetti insoliti sono che ++ e - possono essere usati come prefisso o come postfisso. (...) Nel contesto in cui non si desidera alcun valore (..) scegliere il prefisso o il postfisso secondo i propri gusti. Ma i problemi sono situazioni in cui l'uno o l'altro è specificamente richiesto.

Il testo continua con alcuni esempi che utilizzano incrementi all'interno dell'indice, con l'obiettivo esplicito di scrivere codice " più compatto ". Quindi la ragione dietro questi operatori è la convenienza di un codice più compatto.

I tre esempi forniti ( squeeze(), getline()e strcat()) usano solo postfix all'interno delle espressioni usando l'indicizzazione. Gli autori confrontano il codice con una versione più lunga che non utilizza incrementi incorporati. Ciò conferma che l'attenzione è rivolta alla compattezza.

Evidenzia K&R a pagina 102, l'uso di questi operatori in combinazione con la dereferenziazione dei puntatori (ad es. *--pE *p--). Non viene fornito alcun esempio, ma ancora una volta chiariscono che il vantaggio è la compattezza.

Il prefisso è ad esempio molto comunemente usato quando si decrementa un indice o un puntatore che fissa dalla fine.

 int i=0; 
 while (i<10) 
     doit (i++);  // calls function for 0 to 9  
                  // i is 10 at this stage
 while (--i >=0) 
     doit (i);    // calls function from 9 to 0 

Non sono d'accordo con la premessa che ++p, in p++qualche modo, è difficile da leggere o poco chiaro. Uno significa "incrementa p e poi leggi p", l'altro significa "leggi p e quindi incrementa p". In entrambi i casi, l'operatore nel codice è esattamente dove si trova nella spiegazione del codice, quindi se sai cosa ++significa, sai cosa significa il codice risultante.

Puoi creare codice offuscato usando qualsiasi sintassi, ma qui non vedo un caso che è p++/ intrinsecamente offuscato.++p

questo è dal punto di vista di un ingegnere elettrico:

ci sono molti processori che dispongono di operatori post-incremento e pre-decremento integrati allo scopo di mantenere uno stack LIFO (last-in-first-out).

potrebbe essere come:

 float stack[4096];
 int stack_pointer = 0;

 ... 

 #define push_stack(arg) stack[stack_pointer++] = arg;
 #define pop_stack(arg) arg = stack[--stack_pointer];

 ...

non lo so, ma questo è il motivo per cui mi aspetterei di vedere gli operatori di incremento sia prefisso che postfisso.

Per sottolineare il punto di vista di Christophe sulla compattezza, voglio mostrare a tutti voi del codice V6. Questo fa parte del compilatore C originale, da http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/c/c00.c :

/*
 * Look up the identifier in symbuf in the symbol table.
 * If it hashes to the same spot as a keyword, try the keyword table
 * first.  An initial "." is ignored in the hash.
 * Return is a ptr to the symbol table entry.
 */
lookup()
{
    int ihash;
    register struct hshtab *rp;
    register char *sp, *np;

    ihash = 0;
    sp = symbuf;
    if (*sp=='.')
        sp++;
    while (sp<symbuf+ncps)
        ihash =+ *sp++;
    rp = &hshtab[ihash%hshsiz];
    if (rp->hflag&FKEYW)
        if (findkw())
            return(KEYW);
    while (*(np = rp->name)) {
        for (sp=symbuf; sp<symbuf+ncps;)
            if (*np++ != *sp++)
                goto no;
        csym = rp;
        return(NAME);
    no:
        if (++rp >= &hshtab[hshsiz])
            rp = hshtab;
    }
    if(++hshused >= hshsiz) {
        error("Symbol table overflow");
        exit(1);
    }
    rp->hclass = 0;
    rp->htype = 0;
    rp->hoffset = 0;
    rp->dimp = 0;
    rp->hflag =| xdflg;
    sp = symbuf;
    for (np=rp->name; sp<symbuf+ncps;)
        *np++ = *sp++;
    csym = rp;
    return(NAME);
}

Questo codice è stato diffuso in samizdat come un'istruzione di buon stile, eppure oggi non lo scriveremmo mai così. Osserva quanti effetti collaterali sono stati inseriti ife le whilecondizioni e , al contrario, in che modo entrambi i forloop non hanno un'espressione incrementale perché è presente nel corpo del loop. Guarda come i blocchi vengono avvolti tra parentesi graffe solo quando assolutamente necessario.

Parte di questo era sicuramente la micro-ottimizzazione manuale del tipo che ci aspettiamo che il compilatore faccia per noi oggi, ma vorrei anche avanzare l'ipotesi che quando tutta la tua interfaccia con il computer è una singola tty di vetro 80x25, vuoi il tuo codice essere il più denso possibile in modo da poterne vedere di più contemporaneamente.

(L'uso di buffer globali per tutto è probabilmente una sbornia dal taglio dei denti sul linguaggio assembly.)

Forse dovresti pensare anche ai cosmetici.

while( i++ )

probabilmente "sembra migliore" di

while( i+=1 )

Per qualche motivo, l'operatore post-incremento sembra molto interessante. È breve, dolce e aumenta tutto di 1. Confrontalo con il prefisso:

while( ++i )

"guarda indietro" non è vero? Non vedi mai un segno più PRIMA in matematica, tranne quando qualcuno è sciocco nel specificare qualcosa di positivo ( +0o qualcosa del genere). Siamo abituati a vedere OGGETTO + QUALCOSA

Ha a che fare con la valutazione? A, A +, A ++? Posso dirti che all'inizio ero piuttosto sconcertato dal fatto che le persone di Python si allontanassero operator++dalla loro lingua!

Conteggio all'indietro da 9 a 0 incluso:

for (unsigned int i=10; i-- > 0;)  {
    cout << i << " ";
}

O l'equivalente ciclo while.