Perché 0 è falso?

110

Questa domanda può sembrare stupida, ma perché 0 valuta in false e qualsiasi altro [valore intero] in true è la maggior parte dei linguaggi di programmazione?

Confronto tra stringhe

Dato che la domanda sembra un po 'troppo semplice, mi spiegherò un po' di più: prima di tutto, potrebbe sembrare evidente a qualsiasi programmatore, ma perché non ci sarebbe un linguaggio di programmazione - potrebbe esserci effettivamente, ma non ne ho usato nessuno - dove 0 valuta a true e tutti gli altri valori [interi] a false ? Quella osservazione può sembrare casuale, ma ho alcuni esempi in cui potrebbe essere stata una buona idea. Prima di tutto, prendiamo l'esempio del confronto a tre vie delle stringhe, prenderò come esempio il strcmp di C: qualsiasi programmatore che prova C come sua prima lingua potrebbe essere tentato di scrivere il seguente codice:

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

Poiché strcmp restituisce 0 che restituisce false quando le stringhe sono uguali, ciò che il programmatore iniziale ha cercato di fare fallisce miseramente e generalmente non capisce perché all'inizio. Se 0 fosse stato valutato a true , questa funzione avrebbe potuto essere utilizzata nella sua espressione più semplice, quella sopra, quando si confrontava per l'uguaglianza, e i controlli appropriati per -1 e 1 sarebbero stati eseguiti solo quando necessario. Avremmo considerato il tipo di ritorno come bool (nella nostra mente, intendo) la maggior parte del tempo.

Inoltre, introduciamo un nuovo tipo, sign , che prende solo i valori -1 , 0 e 1 . Questo può essere molto utile. Immagina che ci sia un operatore di astronave in C ++ e lo vogliamo per std::string (beh, c'è già il compare funzione, ma l'operatore di astronave è più divertente). La dichiarazione sarebbe attualmente la seguente:

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

Had 0 è stato valutato a true , l'operatore di astronave non esisterebbe nemmeno e potremmo aver dichiarato operator== in questo modo:

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

Questo operator== avrebbe gestito il confronto a tre vie in una sola volta, e potrebbe ancora essere utilizzato per eseguire il seguente controllo pur essendo in grado di verificare quale stringa è lessicograficamente superiore all'altra quando necessario:

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

Gestione degli errori precedenti

Ora abbiamo delle eccezioni, quindi questa parte si applica solo alle vecchie lingue in cui non esiste nulla (C per esempio). Se guardiamo alla libreria standard di C (e anche a POSIX), possiamo vedere con certezza che le funzioni di maaaaany restituiscono 0 quando ha successo e qualsiasi numero intero altrimenti. Ho visto tristemente che alcune persone fanno questo genere di cose:

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

Se pensiamo a come pensiamo nella programmazione, spesso abbiamo il seguente schema di ragionamento:

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

Se ci pensiamo di nuovo, avrebbe avuto senso mettere l'unico valore neutro, 0 , a yes (ed è così che funzionano le funzioni di C), mentre tutti gli altri valori possono essere lì per risolvere il problema molti casi di no . Tuttavia, in tutti i linguaggi di programmazione che conosco (tranne forse alcuni linguaggi esoterici sperimentali), che yes valuta in false in una condizione if , mentre tutti i casi no valutano in true . Ci sono molte situazioni in cui "funziona" rappresenta un caso mentre "non funziona" rappresenta molte cause probabili. Se ci pensiamo in questo modo, avere 0 valuta a true e il resto a false avrebbe avuto molto più senso.

Conclusione

La mia conclusione è essenzialmente la mia domanda iniziale: perché abbiamo progettato linguaggi in cui 0 è false e gli altri valori sono true , prendendo in considerazione i miei pochi esempi sopra e forse qualcosa in più a cui non avevo pensato?

Follow-up: È bello vedere che ci sono molte risposte con molte idee e tante possibili ragioni per farlo. Amo quanto ti sembra appassionato. Ho fatto questa domanda originariamente per noia, ma visto che sembri così appassionato, ho deciso di andare un po 'oltre e di chiedere alla logica dietro la scelta booleana per 0 e 1 su Math.SE:)

    
posta Morwenn 15.05.2013 - 21:37
fonte

14 risposte

97

0 è false perché sono entrambi zero elementi nelle comuni semirings . Anche se si tratta di tipi di dati distinti, è intuitivo convertirli tra loro perché appartengono a strutture algebriche isomorfe.

  • 0 è l'identità per l'addizione e zero per la moltiplicazione. Questo vale per numeri interi e razionali, ma non numeri a virgola mobile IEEE-754: 0.0 * NaN = NaN e 0.0 * Infinity = NaN .

  • false è l'identità per Booleano xor (⊻) e zero per Booleano e (∧). Se Booleans sono rappresentati come {0, 1} - l'insieme di interi modulo 2 - puoi pensare a ⊻ come addizione senza carry e ∧ come moltiplicazione.

  • "" e [] sono identità per la concatenazione, ma esistono diverse operazioni per le quali hanno senso come zero. La ripetizione è una, ma la ripetizione e la concatenazione non vengono distribuite, quindi queste operazioni non formano un semiring.

Tali conversioni implicite sono utili in piccoli programmi, ma in generale possono rendere i programmi più difficili da ragionare. Solo uno dei tanti compromessi nella progettazione della lingua.

    
risposta data 16.05.2013 - 05:47
fonte
74

Perché la matematica funziona.

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

... insert many other examples here.

Tradizionalmente, i programmi C hanno condizioni come

if (someFunctionReturningANumber())

anziché

if (someFunctionReturningANumber() != 0)

perché il concetto di zero è equivalente a falso è ben compreso.

    
risposta data 15.05.2013 - 21:52
fonte
38

Come altri hanno già detto, la matematica è stata la prima. Questo è il motivo per cui 0 è false e 1 è true .

Di quale matematica stiamo parlando? algebre booleane che risalgono alla metà del 1800, molto prima che i computer digitali arrivassero.

Potresti anche dire che la convenzione è uscita dalla logica proposizionale , che è persino più vecchia delle algebre booleane. Questa è la formalizzazione di molti dei risultati logici che i programmatori conoscono e amano ( false || x equivale a x , true && x equivale a x e così via).

Fondamentalmente stiamo parlando di aritmetica su un set con due elementi. Pensa al conteggio in binario. Le algebre booleane sono l'origine di questo concetto e la sua base teorica. Le convenzioni di linguaggi come C sono solo un'applicazione semplice.

    
risposta data 15.05.2013 - 22:08
fonte
26

Pensavo che questo avesse a che fare con "l'ereditarietà" dell'elettronica, e anche con l'algebra booleana, dove

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

strcmp restituisce 0 quando le stringhe sono uguali ha a che fare con la sua implementazione, poiché ciò che effettivamente fa è calcolare la "distanza" tra le due stringhe. Che 0 sia anche considerato falso è solo una coincidenza.

restituire 0 in caso di successo ha senso perché 0 in questo caso è usato per significare nessun errore e qualsiasi altro numero sarebbe un codice di errore. L'uso di qualsiasi altro numero per il successo avrebbe molto meno senso dal momento che si ha un solo codice di successo, mentre è possibile avere diversi codici di errore. Tu usi "Ha funzionato?" come l'espressione if statement e dire 0 = yes avrebbe più senso, ma l'espressione è più corretta "Qualcosa è andato storto?" e poi vedi che 0 = no ha molto senso. Pensare a false/true non ha davvero senso qui, dato che è in realtà no error code/error code .

    
risposta data 16.05.2013 - 12:44
fonte
18

Come spiegato in questo articolo , i valori false e true non devono essere confusi con gli interi 0 e 1, ma possono essere identificati con gli elementi del campo di Galois (campo finito) di due elementi (vedi qui ).

Un campo è un insieme con due operazioni che soddisfano determinati assiomi.

I simboli 0 e 1 sono usati convenzionalmente per indicare le identità additive e moltiplicative di un campo perché i numeri reali sono anche un campo (ma non uno finito) le cui identità sono i numeri 0 e 1.

L'identità additiva è l'elemento 0 del campo, tale che per tutti x:

x + 0 = 0 + x = x

e l'identità moltiplicativa è l'elemento 1 del campo, tale che per tutti x:

x * 1 = 1 * x = x

Il campo finito di due elementi ha solo questi due elementi, vale a dire l'identità additiva 0 (o false ) e l'identità moltiplicativa 1 (o true ). Le due operazioni di questo campo sono il logico XOR (+) e il logico AND (*).

Nota. Se capovolgi le operazioni (XOR è la moltiplicazione e AND è l'addizione), allora la moltiplicazione non è più distributiva per aggiunta e non hai più un campo. In tal caso non hai motivo di chiamare i due elementi 0 e 1 (in qualsiasi ordine). Nota anche che non puoi scegliere l'operazione OR invece di XOR: indipendentemente da come interpreti OR / AND come addizione / moltiplicazione, la struttura risultante non è un campo (non tutti gli elementi inversi esistono come richiesto dagli assiomi del campo).

Per quanto riguarda le funzioni C:

  • Molte funzioni restituiscono un intero che è un codice di errore. 0 significa NO ERROR.
  • Intuitivamente, la funzione strcmp calcola la differenza tra due stringhe. 0 significa che non c'è differenza tra due stringhe, cioè che due stringhe sono uguali.

Le spiegazioni intuitive di cui sopra possono aiutare a ricordare l'interpretazione dei valori di ritorno, ma è ancora più semplice controllare semplicemente la documentazione della biblioteca.

    
risposta data 16.05.2013 - 00:21
fonte
13

Dovresti considerare che i sistemi alternativi possono anche essere decisioni progettuali accettabili.

Conchiglie: 0 stato di uscita è vero, diverso da zero è falso

L'esempio di shell che considera lo stato di uscita 0 come vero è già stato menzionato.

$ ( 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

La logica è che c'è un modo per avere successo, ma molti modi per fallire, quindi usare 0 come valore speciale che significa "nessun errore" è pragmatico.

Ruby: 0 è come qualsiasi altro numero

Tra i linguaggi di programmazione "normali" ci sono alcuni valori anomali, come Ruby, che considerano 0 come valore vero.

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

La motivazione è che solo false e nil devono essere false. Per molti novizi di Ruby, è un trucco. Tuttavia, in alcuni casi, è bello che 0 sia trattato come qualsiasi altro numero.

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"

Tuttavia, tale sistema funziona solo in una lingua che è in grado di distinguere i booleani come un tipo separato dai numeri. Nei primi giorni dell'informatica, i programmatori che lavoravano con linguaggio assembly o linguaggio macchina grezza non avevano tali lussi. È probabilmente naturale considerare 0 come stato "vuoto" e impostare un bit su 1 come flag quando il codice rileva che qualcosa è successo. Per estensione, la convenzione ha sviluppato che lo zero è stato trattato come falso e che i valori diversi da zero sono stati trattati come veri. Tuttavia, non deve essere in questo modo.

Java: i numeri non possono essere trattati come booleani

In Java, true e false sono gli unici valori booleani. I numeri non sono booleani e non possono essere inseriti nei booleani ( Java Specifica della lingua, sezione 4.2.2 ):

There are no casts between integral types and the type boolean.

Questa regola evita del tutto la domanda - tutte le espressioni booleane devono essere esplicitamente scritte nel codice.

    
risposta data 10.04.2014 - 20:54
fonte
8

Prima di affrontare il caso generale, possiamo discutere dei tuoi esempi di contro.

Confronto tra stringhe

Lo stesso vale per molti tipi di confronti, in realtà. Tali confronti calcolano una distanza tra due oggetti. Quando gli oggetti sono uguali, la distanza è minima. Quindi, quando "il confronto ha successo", il valore è 0. Ma in realtà, il valore di ritorno di strcmp è non un booleano, è una distanza e ciò che intrappola i programmatori inconsapevoli che fanno if (strcmp(...)) do_when_equal() else do_when_not_equal() .

In C ++ potremmo ridisegnare strcmp per restituire un oggetto Distance , che sovrascrive operator bool() per restituire true quando 0 (ma verrai morso da un diverso insieme di problemi). O semplicemente in C basta avere una funzione streq che restituisce 1 quando le stringhe sono uguali e 0 altrimenti.

Chiamate API / codice di uscita del programma

Qui ti interessa il motivo per cui qualcosa è andato storto, perché questo porterà le decisioni all'errore. Quando le cose vanno bene, non vuoi sapere nulla in particolare - il tuo intento è realizzato. Il valore di ritorno deve quindi trasmettere questa informazione. È non un booleano, è un codice di errore. Il valore di errore speciale 0 significa "nessun errore". Il resto dell'intervallo rappresenta errori localmente significativi che devi affrontare (incluso 1, che spesso significa "errore non specificato").

Caso generale

Questo ci lascia con la domanda: perché i valori booleani True e False comunemente rappresentati con 1 e 0, rispettivamente?

Bene, oltre all'argomento "si sente meglio in questo modo", ecco alcuni motivi (anche soggettivi) a cui posso pensare:

  • analogia del circuito elettrico. La corrente è ON per 1s e OFF per 0s. Mi piace avere (1, Sì, True, On) insieme e (0, No, False, Off), piuttosto che un altro mix

  • inizializzazioni di memoria. Quando I memset(0) un gruppo di variabili (siano esse inte, float, bool) voglio che il loro valore corrisponda alle ipotesi più prudenti. Per esempio. la mia somma è inizialmente 0, il predicato è Falso, ecc.

Forse tutte queste ragioni sono legate alla mia educazione - se mi fosse stato insegnato ad associare 0 a True dall'inizio, andrei per il contrario.

    
risposta data 15.05.2013 - 23:23
fonte
6

Da una prospettiva di alto livello, stai parlando di tre tipi di dati completamente diversi:

  1. Un booleano. La convenzione matematica in algebra booleana usa 0 per false e 1 per true , quindi ha senso seguire questa convenzione. Penso che in questo modo abbia anche più senso in modo intuitivo.

  2. Il risultato del confronto. Questo ha tre valori: < , = e > (notare che nessuno di loro è true ). Per loro ha senso usare i valori di -1, 0 e 1, rispettivamente (o, più in generale, un valore negativo, zero e un valore positivo).

    Se vuoi controllare l'uguaglianza e hai solo una funzione che esegue un confronto generale, penso che dovresti renderlo esplicito usando qualcosa come strcmp(str1, str2) == 0 . Trovo che l'utilizzo di ! in questa situazione confonda, perché tratta un valore non booleano come se fosse un booleano.

    Inoltre, tieni presente che il confronto e l'uguaglianza non devono essere la stessa cosa. Ad esempio, se ordini le persone in base alla loro data di nascita, Compare(me, myTwin) dovrebbe restituire 0 , ma Equals(me, myTwin) dovrebbe restituire false .

  3. Il successo o il fallimento di una funzione, possibilmente anche con dettagli su tale successo o fallimento. Se parli di Windows, questo tipo si chiama HRESULT e un valore diverso da zero non necessariamente indicare fallimento. Infatti, un valore negativo indica un fallimento e un successo non negativo. Il valore di successo è molto spesso S_OK = 0 , ma può anche essere ad esempio S_FALSE = 1 o altri valori.

La confusione deriva dal fatto che tre tipi di dati logicamente molto diversi sono in realtà rappresentati come un singolo tipo di dati (un intero) in C e in alcuni altri linguaggi e che è possibile utilizzare un intero in una condizione. Ma non penso che avrebbe senso ridefinire il valore booleano per rendere più semplice l'uso di alcuni tipi non booleani.

Inoltre, considera un altro tipo che viene spesso utilizzato in una condizione in C: un puntatore. In questo caso, è naturale trattare un NULL -pointer (che è rappresentato come 0 ) come false . Quindi seguire il tuo suggerimento renderebbe anche più difficile lavorare con i puntatori. (Anche se, personalmente, preferisco confrontare esplicitamente i puntatori con NULL , invece di trattarli come booleani.)

    
risposta data 15.05.2013 - 23:36
fonte
4

Zero può essere falso perché la maggior parte delle CPU ha un flag ZERO che può essere usato per diramarsi. Salva un'operazione di confronto.

Vediamo perché.

Alcuni psuedocode, poiché il pubblico probabilmente non legge l'assembly

fonte c chiamate di loop semplici wibble 10 volte

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

alcuni finti assemblaggi per questo

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  

fonte c un altro ciclo semplice chiama il wibble 10 volte

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

alcuni finti assemblaggi per questo caso

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  

qualche altra fonte c

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

e l'assemblaggio

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

guarda quanto è breve?

qualche altra fonte c

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

e l'assembly (assumiamo un compilatore marginalmente intelligente che può sostituire == 0 senza confronto)

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

Ora proviamo una convenzione di true = 1

qualche altra fonte c     #define TRUE 1     int foo = TRUE;     if (foo == TRUE) wibble ()

e l'assemblaggio

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

vedi quanto è breve il caso con non vero zero?

In realtà le prime CPU avevano piccoli set di bandiere collegate all'accumulatore.

Per verificare se a > b o a = b generalmente richiede un'istruzione di confronto.

  • A meno che B sia o ZERO - nel qual caso viene impostato il flag ZERO Implementato come semplice NOR logico o tutti i bit nell'accumulatore.
  • O NEGATIVO in cui basta usare il "bit di segno", cioè il bit più significativo dell'Accumulatore se si utilizza l'aritmetica del complemento a due. (Principalmente lo facciamo)

Consente di riformulare questo. Su alcune CPU meno recenti non è necessario utilizzare un'istruzione di confronto per accumulatore uguale a ZERO o accumulatore inferiore a zero.

Ora capisci perché lo zero potrebbe essere falso?

Si noti che questo è psuedo-code e nessun set di istruzioni reali sembra proprio questo. Se conosci l'assemblea, sai che sto semplificando molto le cose qui. Se sai qualcosa sulla progettazione del compilatore, non hai bisogno di leggere questa risposta. Chiunque sappia qualcosa sullo svolgimento del ciclo o sulla previsione delle diramazioni, la classe avanzata è in fondo alla sala nella stanza 203.

    
risposta data 16.05.2013 - 11:34
fonte
3

Ci sono molte risposte che suggeriscono che la corrispondenza tra 1 e vero è necessaria per alcune proprietà matematiche. Non riesco a trovare alcuna proprietà del genere e suggerisco che si tratti di una convenzione puramente storica.

Dato un campo con due elementi, abbiamo due operazioni: addizione e moltiplicazione. Possiamo mappare le operazioni booleane su questo campo in due modi:

Tradizionalmente, identifichiamo True con 1 e False con 0. Identifichiamo AND con * e XOR con +. Così OR sta aggiungendo la saturazione.

Tuttavia, possiamo facilmente identificare True con 0 e False con 1. Quindi identifichiamo OR con * e XNOR con +. Così AND sta saturando l'aggiunta.

    
risposta data 16.05.2013 - 00:01
fonte
3

Stranamente, zero non è sempre falso.

In particolare, la convenzione Unix e Posix consiste nel definire EXIT_SUCCESS come 0 (e EXIT_FAILURE come 1). In realtà è anche una convenzione C !

standard

Quindi per shell Posix e exit (2) syscalls, 0 significa "riuscito "che intuitivamente è più vero che falso.

In particolare, if della shell vuole un ritorno del processo EXIT_SUCCESS (cioè 0) per seguire il suo ramo "allora"!

In Scheme (ma non in Common Lisp o in MELT ) 0 e nil (cioè () in Scheme) sono veri, poiché l'unico valore falso è #f

Sono d'accordo, sto pignolando!

    
risposta data 28.07.2014 - 15:07
fonte
3

C viene utilizzato per la programmazione di basso livello vicino all'hardware, un'area in cui a volte è necessario passare da operazioni bit a bit a operazioni logiche, sugli stessi dati. Essendo richiesto di convertire un'espressione numerica in booleana solo per eseguire un test, ingombra il codice.

Puoi scrivere cose come:

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

anziché

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

In un esempio isolato non è così male, ma doverlo fare diventerà fastidioso.

Allo stesso modo, le operazioni inverse. È utile per il risultato di un'operazione booleana, come un confronto, produrre solo uno 0 o 1: Supponiamo di voler impostare il terzo bit di una parola in base al fatto che modemctrl abbia il bit di rilevamento portante:

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

Qui dobbiamo avere il != 0 , per ridurre il risultato dell'espressione biwise & a 0 o 1 , ma poiché il risultato è solo un numero intero, non riusciamo ad aggiungere alcuni cast fastidioso per convertire ulteriormente booleano in intero.

Anche se il C moderno ora ha un tipo bool , conserva comunque la validità del codice in questo modo, sia perché è una buona cosa, sia a causa della massiccia rottura con la retrocompatibilità che sarebbe altrimenti causata.

Un altro exmaple in cui C è slick: testare due condizioni booleane come un commutatore a quattro vie:

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

Non puoi portarlo via dal programmatore C senza combattere!

Infine, C a volte serve come una sorta di linguaggio di assemblaggio di alto livello. Nei linguaggi di assembly, non abbiamo tipi booleani. Un valore booleano è solo un bit o un valore zero rispetto a un valore diverso da zero in una posizione o registro di memoria. Un numero intero zero, lo zero booleano e l'indirizzo zero sono tutti testati allo stesso modo in insiemi di istruzioni in linguaggio assembly (e forse anche in virgola mobile zero). La somiglianza tra C e il linguaggio assembly è utile, ad esempio quando C è usato come lingua di destinazione per compilare un'altra lingua (anche una che ha booleani strongmente tipizzati!)

    
risposta data 16.05.2013 - 03:16
fonte
0

Un valore booleano o di verità ha solo 2 valori. Vero e falso.

Questi non dovrebbero essere rappresentati come numeri interi, ma come bit (0 e 1).

Dire qualsiasi altro intero accanto a 0 o 1 non è falso è un'affermazione confusa. Le tabelle di verità trattano i valori di verità, non i numeri interi.

Da un potenziale valore di verità, -1 o 2 infrangerebbero tutte le tabelle di verità e qualsiasi logica booleana associata a loro.

  • 0 AND -1 ==?!
  • 0 OR 2 ==?!

La maggior parte delle lingue di solito ha un tipo boolean che, quando viene lanciato su un numero, come un intero rivela false per essere lanciato come valore intero di 0.

    
risposta data 15.05.2013 - 23:17
fonte
-6

In definitiva, stai parlando di rompere il linguaggio principale perché alcune API sono schifose. Le API crappy non sono nuove e non è possibile correggerle rompendo la lingua. È un fatto matematico che 0 è falso e 1 è vero, e qualsiasi linguaggio che non rispetta questo è fondamentalmente rotto. Il confronto a tre vie è di nicchia e non ha alcuna attività in cui il suo risultato è implicitamente convertito in bool poiché restituisce tre risultati possibili. Le vecchie API C hanno semplicemente una terribile gestione degli errori e sono anche ostacolate perché C non ha le funzionalità linguistiche necessarie per non avere interfacce terribili.

Nota che non sto dicendo che per le lingue che non hanno una conversione implicita di interi e gt; booleani.

    
risposta data 15.05.2013 - 21:52
fonte

Leggi altre domande sui tag