Le versioni scritte degli operatori logici


94

Questo è l'unico posto che abbia mai visto and, ore notindicato come operatori reali in C ++. Quando ho scritto un programma di test in NetBeans, ho ottenuto la sottolineatura rossa come se ci fosse un errore di sintassi e ho capito che il sito web era sbagliato, ma è NetBeans che è sbagliato perché è stato compilato ed eseguito come previsto.

Vedo !essere favorito, notma la leggibilità di and&& orsembra maggiore dei loro fratelli grammaticali. Perché esistono queste versioni degli operatori logici e perché apparentemente nessuno le usa? Questo C ++ è veramente valido o una sorta di compatibilità con il C incluso nel linguaggio?


4
\ me Riscrive tutto il suo codice
Espiazione limitata

2
nello spirito del "codice pulito" consiglierei personalmente di farla finita con l'abitudine di scrivere ||e &&, forse anche !a volte. Le parole sono sempre migliori di "rumore di linea", per non parlare della possibile confusione con gli operatori di manipolazione dei bit.
Ichthyo

2
@Ichthyo Questo non è sempre corretto. È molto più veloce leggere molti simboli e conoscerne il significato, piuttosto che leggere molte parole.
vallentin

ciò che è più chiaro per un lettore umano dipende dalla "Gestalt". A volte un simbolo può essere più chiaro di un termine confuso, ma in questo caso non lo è. E le parole semplici della lingua inglese sono molto più universali di alcuni strani simboli speciali di un linguaggio di programmazione un po 'strano ...
Ichthyo

3
L'ironia di dire che andè più leggibile e poi scrivere " and&& or" però :)
Ivan Vergiliev

Risposte:


111

Hanno avuto origine in C nell'intestazione <iso646.h>. A quel tempo c'erano tastiere che non potevano digitare i simboli richiesti per &&(ad esempio), quindi l'intestazione conteneva #definegli elementi che li avrebbero aiutati a farlo, definendo (nel nostro esempio) andessere &&. Naturalmente, con il passare del tempo, questo è diventato meno utilizzato.

In C ++, sono diventati i cosiddetti token alternativi . Non è necessario includere nulla per utilizzare questi token in un compilatore conforme (in quanto tale, la versione C ++ ified dell'intestazione C,, <ciso646>è vuota). I token alternativi sono proprio come i token normali, ad eccezione dell'ortografia. Quindi durante l'analisi andè esattamente lo stesso &&, è solo un modo diverso di scrivere la stessa cosa.

Per quanto riguarda il loro utilizzo: poiché sono usati raramente, usarli è spesso più sorprendente e confuso di quanto non sia utile. Sono sicuro che se fosse normale, sarebbero molto più facili da leggere, ma le persone sono così abituate &&e ||qualsiasi altra cosa distrae.

EDIT: ho visto un leggero aumento del loro utilizzo da quando l'ho pubblicato, tuttavia. Li evito ancora.


Quindi l'interpretazione di questi token alternativi è solo una funzionalità del compilatore o è nella specifica C ++?
asfalto difettoso

2
@Kavon: è specificato nella sezione 2.5 dello standard; è una caratteristica della lingua.
GManNickG

15
Personalmente penso che siano molto meglio ... ma poi sono di parte di Python. Non so perché alcune persone pensano che se non è confuso non è un codice ...
Matthieu M.

Quindi questi non sono validi in C senza includere quel file di intestazione? Sono sorpreso che questi non siano usati da tutti; rendono Python molto più leggibile.
endolith

1
Almeno Visual Studio 2015 CTP 6 non mi piaceva oro notsenza includere l'intestazione.
usr1234567

18

Esistono per l'usabilità (supporto dei caratteri nei gusti tastiera / display) e leggibilità generale, ma c'è un altro motivo che al giorno d'oggi è più pronunciato. Quasi nessuna delle risposte qui , qui , o anche la risposta principale quiSpiega il motivo principale per cui molti di noi preferiscono le versioni delle parole rispetto alle versioni dei simboli (e un motivo principale per cui le altre lingue le usano): bug. Le differenze tra le versioni delle parole sono molto visibili. Le differenze tra le versioni dei simboli sono nettamente minori, al punto da tentare i bug in misura relativamente molto maggiore: "x | y" non è molto "x || y", tuttavia quando è incorporato in un'espressione più ampia molti di noi perdere la differenza. È simile alla comune combinazione accidentale dell'assegnazione e dell'operatore di uguaglianza. Per questo motivo mi sono allontanato dalle versioni dei simboli (non è stato facile) a favore delle versioni delle parole. Preferirei che qualcuno li affrontasse in due per il nostro amore per le cose vecchie piuttosto che tentare gli insetti.


4
Sfortunatamente, in Visual Studio (a partire da VS2013), è necessario impostare un'opzione specifica del compilatore ( /Za) per supportare le parole chiave alternative (vedere stackoverflow.com/a/555524/368896 ). Questo presumibilmente ha anche altri impatti. Quindi, in Visual Studio, non è necessariamente sicuro seguire questo consiglio.
Dan Nissenbaum

FWIW / - come ho messo gli spazi intorno agli operatori, x | yè sufficientemente distinto visivamente (nei caratteri a spaziatura fissa) da x || y, ma trovo che sia più facile non vederlo, !ad esempio . if (!f(xyz) && ...if (not f(xyz) && ...
Tony Delroy

@Tony D quando metti degli spazi attorno agli operatori, questa è una tua convenzione privata e non ovvia per il lettore. Ma l'uso di parole in linguaggio naturale come and, ore notin un'espressione booleana, migliora effettivamente la leggibilità e mette in evidenza la distinzione tra manipolazioni di bit. Quindi IMHO dovremmo considerare di cambiare le nostre amate vecchie abitudini in meglio ...
Ichthyo,

@DanNissenbaum Ho trovato questa opzione sotto il nome C / C ++> Lingua> Disabilita estensioni lingua , quindi è relativamente sicuro aspettarsi effetti collaterali;)
Wolf

6
Sai quanti bug di Python sono stati introdotti perché le parole ande orle persone influenzano il pensiero di come dovrebbero funzionare? Ad esempio, if (a == b or c)invece di if (a == b || a == c)- qualcosa del genere si apre quasi ogni giorno qui su StackOverflow. I simboli astratti scollegati dalla lingua inglese riducono questi errori.
Mark Ransom

10

In C ++, sono parole chiave reali. In C, sono macro definite in <iso646.h>. Vedi http://web.archive.org/web/20120123073126/http://www.dinkumware.com/manuals/?manual=compleat&page=iso646.html .


6
Tecnicamente sono token alternativi, non parole chiave. :)
GManNickG

2
@GMan: +1 Bella chiamata, però, la pagina Dinkumware le chiama parole chiave, quindi, suppongo che a loro non importasse troppo della distinzione.
Chris Jester-Young


Quindi, MSVC li supporta immediatamente in C ++ ma non in C?
rwst

1
@rwst Non posso commentare specificamente MSVC, ma se implementa fedelmente gli standard C ++ e C, allora sarà davvero così. Vedi anche: stackoverflow.com/questions/2376448/…
Chris Jester-Young,

2

ande &&sono funzionalmente gli stessi in C ++. Gli operatori ande orsono C ++ veramente validi e fanno parte dello standard del linguaggio.

Per approfondire altre risposte con un esempio concreto, c'è un altro motivo oltre solo "leggibilità" a preferire andsopra &&. Spiegare "e" esplicitamente quando un AND logico è ciò che intendi elimina la possibilità di bug sottili.

Considera questo:

int x = 3;
int y = 4;

// Explicitly use "and"
if (x and y) {
    cout << "and: x and y are both non-zero values" << endl;
}

// Using "&&"
if (x && y) {
    cout << "&&: x and y are both non-zero values" << endl;
}

// Oops! I meant to type "&&"!
if (x & y) {
    cout << "&: x and y are both non-zero values" << endl;
}
else {
    cout << "How did I get here?" << endl;
}

Tutte e tre le istruzioni if ​​verranno compilate, ma l'ultima significa qualcosa di completamente diverso e non intenzionale!

Se usi sempre andquando intendi AND logico, non puoi mai digitare accidentalmente un singolo "&" e fare in modo che il tuo codice venga compilato correttamente ed eseguito con risultati misteriosi.

Un altro buon esercizio: prova a tralasciare un carattere "e" per sbaglio e guarda cosa succede. ;)


1
Questa non è davvero una risposta alla domanda. Stai solo affermando ciò che ritieni sia più leggibile. L'OP ha chiesto come funzionano le versioni scritte, non quali sono le migliori. E qualcun altro ha già fatto lo stesso punto che stai cercando di fare.
Nicol Bolas

Non che fornisca davvero informazioni più utili, ma aggiungerò " ande &&sono funzionalmente identici" alla risposta ... E se leggi la mia risposta vedrai che sto dicendo che NON riguarda la leggibilità;)
tjwrona1992
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.