Pisemne wersje operatorów logicznych

To jest jedyne miejsce, jakie kiedykolwiek widziałem and, ora notna liście rzeczywistych operatorów w C ++. Kiedy napisałem program testowy w NetBeans, zauważyłem czerwone podkreślenie, jakby był błąd składniowy i pomyślałem, że witryna jest błędna, ale to NetBeans jest błędny, ponieważ skompilował się i działał zgodnie z oczekiwaniami.

Widzę, !że są faworyzowani, notale czytelność and&& orwydaje się większa niż w przypadku ich braci gramatycznych. Dlaczego te wersje operatorów logicznych istnieją i dlaczego pozornie nikt ich nie używa? Czy to naprawdę poprawne C ++, czy jakaś kompatybilność z C, która została dołączona do języka?

Pochodzą z C w nagłówku <iso646.h>. W tamtym czasie istniały klawiatury, które nie mogły wpisać wymaganych symboli &&(na przykład), więc nagłówek zawierał te #define, które pomogłyby im w tym, poprzez (w naszym przykładzie) zdefiniowanie, andże jest &&. Oczywiście w miarę upływu czasu stawało się to mniej wykorzystywane.

W C ++ stały się tak zwanymi alternatywnymi tokenami . Zdajesz nie muszą obejmować niczego do używania tych znaków w kompilatora zgodnego (jako takie, C ++ - ified wersję nagłówka C, <ciso646>jest puste). Alternatywne tokeny są takie same jak zwykłe tokeny, z wyjątkiem pisowni. Więc podczas parsowania andjest dokładnie to samo &&, co po prostu inny sposób zapisywania tego samego.

Jeśli chodzi o ich użycie: ponieważ są rzadko używane, używanie ich jest często bardziej zaskakujące i zagmatwane niż pomocne. Jestem pewien, że gdyby to było normalne, byłoby dużo łatwiejsze do odczytania, ale ludzie są do tego przyzwyczajeni &&i ||wszystko inne po prostu rozprasza.

EDYCJA: Odkąd to opublikowałem, zauważyłem jednak bardzo niewielki wzrost ich użycia. Nadal ich unikam.

Istnieją one dla użyteczności (obsługa znaków w smakach klawiatury / wyświetlacza) i ogólnej czytelności, ale jest inny powód, który jest obecnie bardziej wyraźny. Prawie żadna z odpowiedzi tutaj , tutaj , ani nawet główna odpowiedź tutajWyjaśnij główny powód, dla którego wielu z nas woli wersje słowne od wersji symboli (i główny powód, dla którego używają ich inne języki): błędy. Różnice między wersjami słów są bardzo widoczne. Różnice między wersjami symboli są znacznie mniejsze, do tego stopnia, że ​​kuszą błędy w stosunkowo dużo większym stopniu: „x | y” w zasadzie nie jest „x || y”, ale gdy jest osadzony w większym wyrażeniu, wielu z nas przegapić różnicę. Jest to podobne do typowego przypadkowego mieszania operatora przypisania i równości. Z tego powodu odsunąłem się od wersji symboli (nie było to łatwe) na rzecz wersji słownych. Wolałbym, żeby ktoś z nich wziął się podwójnie z powodu naszej miłości do starych rzeczy, niż kusić robaki.

W C ++ są prawdziwymi słowami kluczowymi. W C są to makra zdefiniowane w <iso646.h>. Zobacz http://web.archive.org/web/20120123073126/http://www.dinkumware.com/manuals/?manual=compleat&page=iso646.html .

andi &&funkcjonalnie są takie same w C ++. andI oroperatorzy są naprawdę ważne C ++ i częścią standardu językowego.

Wypracowanie na innych odpowiedzi o przykład betonu, nie ma innego powodu, oprócz tylko „czytelności” wolą andponad &&. Wyraźne pisanie „i”, gdy logiczne AND jest tym, co masz na myśli, eliminuje możliwość subtelnych błędów.

Rozważ to:

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;
}

Wszystkie trzy instrukcje if zostaną skompilowane, ale ostatnia oznacza coś zupełnie innego i niezamierzonego!

Jeśli zawsze używasz, andgdy masz na myśli logiczne AND, nigdy nie możesz przypadkowo wpisać pojedynczego znaku „&” i sprawić, że kod zostanie pomyślnie skompilowany i uruchomiony z tajemniczymi wynikami.

Kolejne dobre ćwiczenie: spróbuj przez przypadek pominąć znak „i” i zobacz, co się stanie. ;)