To pytanie może wydawać się głupie, ale dlaczego 0ewaluuje falsei jakąkolwiek inną wartość [całkowitą] trueto większość języków programowania?

Porównanie ciągów

Ponieważ pytanie wydaje się nieco zbyt proste, wyjaśnię się trochę bardziej: po pierwsze, może się wydawać oczywiste dla każdego programisty, ale dlaczego nie byłoby języka programowania - może być, ale nie może Użyłem - gdzie 0ewaluuje truei wszystkie inne wartości [całkowite] false? Ta jedna uwaga może wydawać się przypadkowa, ale mam kilka przykładów, w których może to być dobry pomysł. Po pierwsze, weźmy przykład trójstronnego porównania ciągów, wezmę C strcmpjako przykład: każdy programista próbujący C jako swojego pierwszego języka może ulec pokusie napisania następującego kodu:

if (strcmp(str1, str2)) { // Do something... }

Ponieważ strcmpzwroty, 0które oceniają, falsekiedy łańcuchy są równe, to, co początkowy programista próbował zrobić, kończy się niepowodzeniem i na ogół nie rozumie dlaczego na początku. Oceniając, 0że truezamiast tego, funkcja ta mogłaby zostać użyta w jej najprostszym wyrażeniu - powyższym - przy porównywaniu pod kątem równości, a odpowiednie kontrole dla -1i 1zostałyby wykonane tylko w razie potrzeby. Przez większość czasu uważalibyśmy ten typ zwrotu za bool(naszym zdaniem ).

Ponadto, niech wprowadzi nowy typ, sign, że po prostu ma wartości -1, 0a 1. To może być całkiem przydatne. Wyobraź sobie, że w C ++ jest operator statku kosmicznego i my go potrzebujemy std::string(cóż, jest już comparefunkcja, ale operator statku kosmicznego jest bardziej zabawny). Deklaracja będzie obecnie następująca:

sign operator<=>(const std::string& lhs, const std::string& rhs);

Gdybyśmy 0zostali oceniani true, operator statku kosmicznego nawet by nie istniał i moglibyśmy w operator==ten sposób zadeklarować :

sign operator==(const std::string& lhs, const std::string& rhs);

To operator==poradziłoby sobie z porównywaniem w trzech kierunkach jednocześnie i nadal mogłoby być użyte do wykonania następującego sprawdzenia, a jednocześnie byłoby w stanie sprawdzić, który ciąg znaków jest lepszy leksykograficznie od drugiego w razie potrzeby:

if (str1 == str2) { // Do something... }

Stara obsługa błędów

Mamy teraz wyjątki, więc ta część dotyczy tylko starych języków, w których nic takiego nie istnieje (na przykład C). Jeśli spojrzymy na standardową bibliotekę C (a także POSIX), możemy zobaczyć na pewno, że funkcje maaaaany powrócą 0po pomyślnym zakończeniu, a dowolna liczba całkowita w przeciwnym razie. Niestety niektórzy ludzie robią takie rzeczy:

#define TRUE 0
// ...
if (some_function() == TRUE)
{
    // Here, TRUE would mean success...
    // Do something
}

Jeśli myślimy o tym, jak myślimy w programowaniu, często mamy następujący wzór rozumowania:

Do something
Did it work?
Yes ->
    That's ok, one case to handle
No ->
    Why? Many cases to handle

Jeśli pomyślimy o tym jeszcze raz, sensowne byłoby umieszczenie jedynej wartości neutralnej 0, do yes(i tak działają funkcje C), podczas gdy wszystkie inne wartości mogą tam być, aby rozwiązać wiele przypadków no. Jednak we wszystkich językach programowania, które znam (oprócz być może niektórych eksperymentalnych języków ezoterycznych), które yesoceniają falsepod ifwarunkiem, podczas gdy wszystkie noprzypadki oceniają true. Istnieje wiele sytuacji, w których „to działa” reprezentuje jeden przypadek, podczas gdy „to nie działa” reprezentuje wiele prawdopodobnych przyczyn. Jeśli pomyślimy o tym w ten sposób, dokonanie 0oceny truei reszty do falsebyłoby znacznie bardziej sensowne.

Wniosek

Mój wniosek jest zasadniczo moim pierwotnym pytaniem: dlaczego zaprojektowaliśmy języki, gdzie 0są falsei inne wartości true, biorąc pod uwagę moje kilka przykładów powyżej, a może kilka innych, o których nie myślałem?

Dalsze działania: Miło jest widzieć, że istnieje wiele odpowiedzi z wieloma pomysłami i tak wiele możliwych powodów, aby tak było. Uwielbiam, jak bardzo pasjonujesz się tym. Oryginalnie zadałem to pytanie z nudów, ale ponieważ wydajesz się tak namiętny, postanowiłem pójść nieco dalej i zapytać o uzasadnienie logicznego wyboru dla 0 i 1 na Math.SE :)

0to falsedlatego, że oba są zerowymi elementami we wspólnych semirings . Mimo że są to odrębne typy danych, intuicyjny sens ma konwersja między nimi, ponieważ należą one do izomorficznych struktur algebraicznych.

• 0to tożsamość dodawania i zero dla mnożenia. Dotyczy to liczb całkowitych i wymiernych, ale nie liczb zmiennoprzecinkowych IEEE-754: 0.0 * NaN = NaNi 0.0 * Infinity = NaN.

• falseto tożsamość logiczna xor (⊻) i zero dla logicznej i (∧). Jeśli booleany są reprezentowane jako {0, 1} - zbiór liczb całkowitych modulo 2 - możesz myśleć o ⊻ jako dodatku bez przenoszenia i ∧ jako pomnożeniu.

• ""i []są tożsamością do konkatenacji, ale istnieje kilka operacji, dla których mają sens jako zero. Powtarzanie jest jedno, ale powtarzanie i konkatenacja nie rozdzielają, więc te operacje nie tworzą semiery.

Takie niejawne konwersje są pomocne w małych programach, ale w dużych mogą utrudniać programowanie. To tylko jeden z wielu kompromisów w projektowaniu języka.

Ponieważ matematyka działa.

FALSE OR TRUE is TRUE, because 0 | 1 is 1.

... insert many other examples here.

Tradycyjnie programy C mają takie warunki

if (someFunctionReturningANumber())

zamiast

if (someFunctionReturningANumber() != 0)

ponieważ pojęcie zerowego równoważnika fałszu jest dobrze zrozumiane.

Jak powiedzieli inni, matematyka była najważniejsza. Dlatego 0 to falsei 1 to true.

O której matematyce mówimy? Algebry boolowskie, które pochodzą z połowy XIX wieku, na długo przed pojawieniem się komputerów cyfrowych.

Można również powiedzieć, że konwencja wyszła z logiki zdań , która jest nawet starsza niż algebry boolowskie. Jest to sformalizowanie wielu logicznych wyników, które programiści znają i kochają ( false || xrówna się x, true && xrówna się xitd.).

Zasadniczo mówimy o arytmetyki na zbiorze z dwoma elementami. Pomyśl o liczeniu binarnym. Algebry boolowskie są źródłem tej koncepcji i jej teoretycznych podstaw. Konwencje języków takich jak C to tylko prosta aplikacja.

Myślałem, że ma to związek z „dziedziczeniem” po elektronice, a także algebrą boolowską, gdzie

• 0= off, negative, no,false
• 1= on, positive, yes,true

strcmp zwraca 0, gdy łańcuchy są równe, ma związek z jego implementacją, ponieważ tak naprawdę robi to, aby obliczyć „odległość” między dwoma łańcuchami. To, że 0 również jest uważane za fałszywe, jest tylko zbiegiem okoliczności.

zwracanie 0 po sukcesie ma sens, ponieważ 0 w tym przypadku oznacza brak błędu i każda inna liczba byłaby kodem błędu. Użycie dowolnego innego numeru do sukcesu nie miałoby większego sensu, ponieważ masz tylko jeden kod sukcesu, a możesz mieć kilka kodów błędów. Używasz „Czy to zadziałało?” jako wyrażenie instrukcji if i powiedzenie 0 = yes miałoby większy sens, ale wyrażenie jest bardziej poprawne „Czy coś poszło nie tak?” i wtedy widać, że 0 = nie ma większego sensu. Myślenie o false/truetym naprawdę nie ma sensu, bo tak naprawdę jest no error code/error code.

Jak wyjaśniono w tym artykule , wartości falsei truenie należy ich mylić z liczbami całkowitymi 0 i 1, ale można je utożsamiać z elementami pola Galois (pole skończone) dwóch elementów (patrz tutaj ).

Pole to zbiór dwóch operacji, które spełniają określone aksjomaty.

Symbole 0 i 1 są konwencjonalnie używane do oznaczenia addytywnej i multiplikatywnej tożsamości pola, ponieważ liczby rzeczywiste są również polem (ale nie skończonym), którego tożsamości to liczby 0 i 1.

Tożsamość addytywna to element 0 pola, taki że dla wszystkich x:

x + 0 = 0 + x = x

a tożsamość multiplikatywna to element 1 pola, taki że dla wszystkich x:

x * 1 = 1 * x = x

Pole skończone dwóch elementów ma tylko te dwa elementy, mianowicie addytywną tożsamość 0 (lub false) i multiplikatywną tożsamość 1 (lub true). Dwie operacje tego pola to logiczny XOR (+) i logiczny AND (*).

Uwaga. Jeśli odwrócisz operacje (XOR to mnożenie, a AND to dodawanie), to mnożenie nie rozdziela po dodaniu i nie masz już pola. W takim przypadku nie ma powodu, aby wywoływać dwa elementy 0 i 1 (w dowolnej kolejności). Zauważ też, że nie możesz wybrać operacji OR zamiast XOR: bez względu na to, jak interpretujesz OR / AND jako dodawanie / mnożenie, wynikowa struktura nie jest polem (nie wszystkie elementy odwrotne istnieją zgodnie z wymaganiami aksjomatów pola).

Odnośnie funkcji C:

• Wiele funkcji zwraca liczbę całkowitą, która jest kodem błędu. 0 oznacza BRAK BŁĘDU.
• Intuicyjnie funkcja strcmpoblicza różnicę między dwoma łańcuchami. 0 oznacza, że ​​nie ma różnicy między dwoma ciągami, tzn. Że dwa ciągi są równe.

Powyższe intuicyjne wyjaśnienia mogą pomóc zapamiętać interpretację zwracanych wartości, ale jeszcze łatwiej jest po prostu sprawdzić dokumentację biblioteki.

Należy wziąć pod uwagę, że alternatywne systemy mogą być również akceptowalnymi decyzjami projektowymi.

Powłoki: 0 stan wyjścia jest prawdą, niezerowe to fałsz

Podano już przykład powłok traktujących status wyjścia 0 jako prawdziwy.

$ ( exit 0 ) && echo "0 is true" || echo "0 is false"
0 is true
$ ( exit 1 ) && echo "1 is true" || echo "1 is false"
1 is false

Uzasadnieniem jest to, że istnieje jeden sposób na sukces, ale wiele sposobów na porażkę, więc użycie 0 jako specjalnej wartości oznaczającej „brak błędów” jest pragmatyczne.

Ruby: 0 jest jak każda inna liczba

Wśród „normalnych” języków programowania istnieją pewne wartości odstające, takie jak Ruby, które traktują 0 jako prawdziwą wartość.

$ irb
irb(main):001:0> 0 ? '0 is true' : '0 is false'
=> "0 is true"

Uzasadnieniem jest to, że tylko falsei nilpowinny być fałszywe. Dla wielu nowicjuszy Ruby jest to problem. Jednak w niektórych przypadkach dobrze, że 0 jest traktowane jak każda inna liczba.

irb(main):002:0> (pos = 'axe' =~ /x/) ? "Found x at position #{pos}" : "x not found"
=> "Found x at position 1"
irb(main):003:0> (pos = 'xyz' =~ /x/) ? "Found x at position #{pos}" : "x not found"
=> "Found x at position 0"
irb(main):004:0> (pos = 'abc' =~ /x/) ? "Found x at position #{pos}" : "x not found"
=> "x not found"

Jednak taki system działa tylko w języku, który jest w stanie odróżnić booleany jako osobny typ od liczb. We wcześniejszych czasach komputerów programiści pracujący z językiem asemblera lub surowym językiem maszynowym nie mieli takich luksusów. Prawdopodobnie naturalne jest traktowanie 0 jako stanu „pustego” i ustawianie wartości 1 na flagę, gdy kod wykryje, że coś się wydarzyło. W konsekwencji konwencja opracowała, że ​​zero traktowano jako fałsz, a wartości niezerowe zaczęto traktować jako prawdziwe. Jednak nie musi tak być.

Java: Liczby w ogóle nie mogą być traktowane jako logiczne

W języku Java, truea falsesą tylko wartości logiczne. Liczby nie są liczbami logicznymi i nie można ich nawet przeliczyć na wartości logiczne ( Java Language Specification, Sec 4.2.2 ):

Nie ma rzutowań między typami integralnymi a typem boolean.

Ta reguła po prostu całkowicie eliminuje pytanie - wszystkie wyrażenia logiczne muszą być wyraźnie zapisane w kodzie.

Przed zajęciem się ogólną sprawą możemy omówić twoje przykłady dotyczące przeciwników.

Porównanie ciągów

To samo dotyczy wielu rodzajów porównań. Takie porównania obliczają odległość między dwoma obiektami. Gdy obiekty są równe, odległość jest minimalna. Kiedy więc „porównanie się powiedzie”, wartość wynosi 0. Ale tak naprawdę wartość zwracana niestrcmp jest wartością logiczną, jest to odległość i to, co pułapkuje nieświadomych programistów .if (strcmp(...)) do_when_equal() else do_when_not_equal()

W C ++ możemy przeprojektować, strcmpaby zwrócić Distanceobiekt, który zastępuje operator bool()zwracanie true, gdy 0 (ale wtedy ugryzłby cię inny zestaw problemów). Lub w zwykłym C mają po prostu streqfunkcję, która zwraca 1, gdy łańcuchy są równe, a 0 w przeciwnym razie.

Wywołania API / kod wyjścia programu

Tutaj zależy Ci na tym, dlaczego coś poszło nie tak, ponieważ spowoduje to błędne decyzje. Kiedy wszystko się powiedzie, nie chcesz wiedzieć nic konkretnego - twoje zamiary są realizowane. Zwracana wartość musi zatem przekazywać te informacje. To nie jest wartość logiczna, to kod błędu. Specjalna wartość błędu 0 oznacza „brak błędu”. Reszta zakresu reprezentuje lokalnie znaczące błędy, z którymi musisz sobie poradzić (w tym 1, co często oznacza „nieokreślony błąd”).

Ogólna sprawa

To pozostawia nas z pytaniem: dlaczego są wartości logiczne Truei Falsepowszechnie reprezentowane z 1 i 0, odpowiednio?

Poza subiektywnym argumentem „tak jest lepiej”, oto kilka powodów (również subiektywnych), o których mogę myśleć:

• analogia obwodu elektrycznego. Prąd jest WŁĄCZONY przez 1 s, a WYŁĄCZONY przez 0 s. Lubię mieć (1, Tak, Prawda, Wł.) Razem i (0, Nie, Fałsz, Wył.) Zamiast innej mieszanki

• inicjalizacje pamięci. Kiedy jestem memset(0)zbiorem zmiennych (niezależnie od tego, czy są to liczby całkowite, zmiennoprzecinkowe, boolowe), chcę, aby ich wartość odpowiadała najbardziej konserwatywnym założeniom. Np. Moja suma wynosi początkowo 0, predykat to Fałsz itp.

Być może wszystkie te powody są związane z moją edukacją - gdybym nauczył mnie kojarzyć 0 z True od samego początku, poszedłbym na odwrót.

Z wysokiego poziomu mówisz o trzech zupełnie różnych typach danych:

1. Wartość logiczna. Konwencja matematyczna w algebrze boolowskiej polega na użyciu 0 dla falsei 1 dla true, więc warto stosować się do tej konwencji. Myślę, że ten sposób ma również bardziej intuicyjny sens.

2. Wynik porównania. To ma trzy wartości: <, =i >(Zauważ, że żaden z nich nie jest true). Dla nich sensowne jest użycie odpowiednio wartości -1, 0 i 1 (lub, bardziej ogólnie, wartości ujemnej, zero i wartości dodatniej).

   Jeśli chcesz sprawdzić równość i masz tylko funkcję, która wykonuje ogólne porównanie, myślę, że powinieneś to wyraźnie określić za pomocą czegoś podobnego strcmp(str1, str2) == 0. Używanie !w tej sytuacji jest mylące, ponieważ traktuje wartość niebędącą wartością logiczną tak, jakby była wartością logiczną.

   Pamiętaj też, że porównanie i równość nie muszą być tym samym. Na przykład, jeśli zamówisz ludzi według daty urodzenia, Compare(me, myTwin)powinien powrócić 0, ale Equals(me, myTwin)powinien powrócić false.

3. Sukces lub niepowodzenie funkcji, być może również ze szczegółami na temat tego sukcesu lub niepowodzenia. Jeśli mówisz o systemie Windows, ten typ jest wywoływany, HRESULTa niezerowa wartość niekoniecznie oznacza awarię. W rzeczywistości wartość ujemna oznacza niepowodzenie i nieujemny sukces. Wartość sukcesu jest bardzo często S_OK = 0, ale może to być na przykład S_FALSE = 1inne wartości.

Zamieszanie wynika z faktu, że trzy logicznie całkiem różne typy danych są w rzeczywistości reprezentowane jako pojedynczy typ danych (liczba całkowita) w C i niektórych innych językach oraz że można użyć liczby całkowitej w jednym warunku. Ale nie sądzę, aby sensowne było redefiniowanie wartości logicznej, aby uprościć korzystanie z niektórych typów nie-logicznych.

Weź również pod uwagę inny typ, który jest często używany w warunku w C: wskaźnik. Tam naturalne jest traktowanie jako NULL-pointer (który jest reprezentowany jako 0) jako false. Zatem zastosowanie się do Twojej sugestii utrudniłoby również pracę ze wskaźnikami. (Chociaż osobiście wolę jawnie porównywać wskaźniki NULL, niż traktować je jako logiczne).

Zero może być fałszywe, ponieważ większość procesorów ma flagę ZERO, której można użyć do rozgałęzienia. Zapisuje operację porównania.

Zobaczmy dlaczego.

Niektóre psuedocode, ponieważ publiczność prawdopodobnie nie czyta asemblera

c- źródło prostych wywołań pętli wibble 10 razy

for (int foo =10; foo>0; foo-- ) /* down count loop is shorter */
{  
   wibble();
}

trochę udawać, że to zgromadziło

0x1000 ld a 0x0a      'foo=10
0x1002 call 0x1234    'call wibble()
0x1005 dec a          'foo--
0x1006 jrnz -0x06      'jump back to 0x1000 if not zero
0x1008  

c- źródło kolejnej prostej wywołania pętli wibble 10 razy

for (int foo =0; foo<10; foo-- ) /* up count loop is longer  */
{  
   wibble();
}

trochę udawaj, że to sprawa

0x1000 ld a 0x00      'foo=0
0x1002 call 0x1234    'call wibble()
0x1005 dec a          'foo--
0x1006 cmp 0x0a       'compare foo to 10 ( like a subtract but we throw the result away)
0x1008 jrns -0x08      'jump back to 0x1000 if compare was negative
0x100a  

trochę więcej c źródła

int foo=10;
if ( foo ) wibble()

i zgromadzenie

0x1000 ld a 0x10
0x1002 jz 0x3
0x1004 call 0x1234
0x1007  

widzisz jak to jest krótkie?

trochę więcej c źródła

int foo=10;
if ( foo==0 ) wibble()

i zespół (załóżmy, że marginalnie inteligentny kompilator może zastąpić == 0 bez porównania)

0x1000 ld a 0x10
0x1002 jz 0x3
0x1004 call 0x1234
0x1007  

Teraz wypróbujmy konwencję true = 1

trochę więcej c źródło # zdefiniować PRAWDA 1 int foo = PRAWDA; if (foo == TRUE) wibble ()

i zgromadzenie

0x1000 ld a 0x1
0x1002 cmp a 0x01
0x1004 jz 0x3
0x1006 call 0x1234
0x1009 

widzisz, jak krótki jest przypadek z niezerową wartością true?

Naprawdę wczesne procesory miały małe zestawy flag przymocowane do akumulatora.

Aby sprawdzić, czy a> b lub a = b ogólnie wymaga instrukcji porównania.

• Chyba że B jest albo ZERO - w takim przypadku flaga ZERO jest ustawiona Zaimplementowany jako prosty logiczny NOR lub wszystkie bity w akumulatorze.
• Lub NEGATYWNY, w którym wystarczy użyć „bitu znakowego”, tj. Najbardziej znaczącego bitu Akumulatora, jeśli używasz arytmetyki dopełniacza dwóch. (Głównie tak)

Przeanalizujmy to. Na niektórych starszych procesorach nie trzeba było używać instrukcji porównywania dla akumulatora równego ZERO lub akumulatora mniejszego niż zero.

Czy rozumiesz teraz, dlaczego zero może być fałszywe?

Uwaga: jest to kod psuedo i żaden zestaw instrukcji nie wygląda tak. Jeśli znasz się na montażu, wiesz, że tutaj dużo upraszczam. Jeśli wiesz coś o projektowaniu kompilatora, nie musiałeś czytać tej odpowiedzi. Każdy, kto wie coś na temat rozwijania pętli lub przewidywania gałęzi, klasa zaawansowana jest w korytarzu w pokoju 203.

Istnieje wiele odpowiedzi, które sugerują, że pewna właściwość matematyczna wymaga zgodności między 1 a prawdą. Nie mogę znaleźć żadnej takiej nieruchomości i sugeruję, że jest to konwencja czysto historyczna.

Biorąc pod uwagę pole z dwoma elementami, mamy dwie operacje: dodawanie i mnożenie. Możemy zmapować operacje logiczne na tym polu na dwa sposoby:

Tradycyjnie identyfikujemy Prawda z 1, a Fałsz z 0. Identyfikujemy ORAZ *, a XOR z +. Zatem OR jest nasycającym dodatkiem.

Jednak równie łatwo moglibyśmy zidentyfikować Prawda z 0, a Fałsz z 1. Następnie identyfikujemy OR z * i XNOR z +. Zatem AND jest nasycającym dodatkiem.

O dziwo zero nie zawsze jest fałszywe.

W szczególności konwencja Unix i Posix ma być zdefiniowana EXIT_SUCCESSjako 0 (i EXIT_FAILUREjako 1). W rzeczywistości jest to nawet standardowa konwencja C. !

Tak dla pocisków Posix i exit (2) wywołań systemowych 0 oznacza „sukces”, co intuicyjnie jest bardziej prawdziwe niż fałszywe.

W szczególności powłoka ifchce powrotu procesuEXIT_SUCCESS (czyli 0), aby podążał za swoją gałęzią „wtedy”!

Na schemacie (ale nie we wspólnym Lisp lub MELT ) 0 i zero (tj. Na ()schemacie) są prawdziwe, ponieważ jedyną fałszywą wartością jest#f

^{Zgadzam się, robię dupki!}

C jest używany do programowania niskopoziomowego blisko sprzętu, obszaru, w którym czasami trzeba przechodzić między operacjami bitowymi i logicznymi na tych samych danych. Konieczność konwersji wyrażenia liczbowego na wartość boolowską tylko w celu wykonania testu zaśmieciłaby kod.

Możesz pisać takie rzeczy jak:

if (modemctrl & MCTRL_CD) {
   /* carrier detect is on */
}

zamiast

if ((modemctrl & MCTRL_CD) != 0) {
    /* carrier detect is on */
}

W jednym odosobnionym przykładzie nie jest tak źle, ale zrobienie tego stanie się irytujące.

Podobnie, operacje konwersacyjne. Przydaje się w wyniku operacji boolowskiej, takiej jak porównanie, wygenerowanie 0 lub 1: Załóżmy, że chcemy ustawić trzeci bit jakiegoś słowa na podstawie tego, czy modemctrlbit wykrywa nośną:

flags |= ((modemctrl & MCTRL_CD) != 0) << 2;

Tutaj musimy mieć != 0, aby zredukować wynik &wyrażenia biwise do 0lub1 , ale ponieważ wynik jest tylko liczbą całkowitą, nie musimy dodawać denerwujących rzutów, aby dalej konwertować wartość logiczną na liczbę całkowitą.

Mimo że współczesne C ma teraz booltyp, nadal zachowuje ważność takiego kodu, zarówno dlatego, że jest to dobra rzecz, jak i z powodu ogromnego zerwania z kompatybilnością wsteczną, która byłaby spowodowana inaczej.

Kolejny przykład, w którym C jest zręczny: testowanie dwóch warunków boolowskich jako przełącznika czterokierunkowego:

switch (foo << 1 | bar) {  /* foo and bar booleans are 0 or 1 */
case 0: /* !foo && !bar */
   break;
case 1: /* !foo && bar */
   break;
case 2: /* foo && !bar */
   break;
case 3: /* foo && bar */
   break;
}

Nie można tego zabrać programatorowi C bez walki!

Wreszcie C czasami służy jako rodzaj języka asemblera na wysokim poziomie. W językach asemblera nie mamy również typów boolowskich. Wartość logiczna to tylko odrobina lub zero w stosunku do niezerowej wartości w lokalizacji pamięci lub rejestrze. Liczba całkowita zero, zero logiczne i adres zero są testowane w ten sam sposób w zestawach instrukcji języka asemblera (a być może nawet zmiennoprzecinkowe zero). Podobieństwo między C a językiem asemblera jest przydatne, na przykład, gdy C jest używany jako język docelowy do kompilacji innego języka (nawet takiego, który ma mocno wpisane wartości logiczne!)

Wartość logiczna lub prawda ma tylko 2 wartości. Prawda i fałsz.

Te nie powinny być przedstawione w postaci liczb całkowitych, ale jako bity (0 do 1).

Mówienie, że jakakolwiek inna liczba całkowita oprócz 0 lub 1 nie jest fałszem, jest mylącym stwierdzeniem. Tabele prawdy dotyczą wartości prawdy, a nie liczb całkowitych.

Z perspektywy wartości prawdy -1 lub 2 złamałoby wszystkie tabele prawdy i związaną z nimi logikę boolowską.

• 0 ORAZ -1 ==?!
• 0 LUB 2 ==?!

Większość języków ma zazwyczaj booleantyp, który po rzutowaniu na typ liczbowy, taki jak liczba całkowita, ujawnia wartość false do rzutowania jako liczba całkowita 0.

Ostatecznie mówisz o złamaniu podstawowego języka, ponieważ niektóre interfejsy API są kiepskie. Crappy APIs nie są nowe i nie można ich naprawić, łamiąc język. Jest matematycznym faktem, że 0 jest fałszem, a 1 jest prawdą, a każdy język, który tego nie szanuje, jest zasadniczo uszkodzony. Trójstronne porównanie jest niszowe i nie ma żadnego interesu, ponieważ jego wynik niejawnie przekształca się wbool ponieważ zwraca trzy możliwe wyniki. Stare interfejsy API C po prostu mają straszliwą obsługę błędów, a także są hamowane, ponieważ C nie ma niezbędnych funkcji językowych, aby nie mieć strasznych interfejsów.

Zauważ, że nie mówię tego w przypadku języków, które nie mają niejawnej konwersji liczb całkowitych-> boolowskich.