¿Por qué es 0 falso?

110

Esta pregunta puede parecer estúpida, pero ¿por qué 0 evalúa a false y cualquier otro valor [entero] a true es la mayoría de los lenguajes de programación?

Comparación de cadenas

Ya que la pregunta parece demasiado simple, me explicaré un poco más: en primer lugar, puede parecer evidente para cualquier programador, pero ¿por qué no habría un lenguaje de programación? pero no he usado ninguno, donde 0 se evalúa como true y todos los demás valores [enteros] a false ? Esa observación puede parecer aleatoria, pero tengo algunos ejemplos en los que puede haber sido una buena idea. En primer lugar, tomemos el ejemplo de las cadenas de tres vías de comparación, tomaré el ejemplo de strcmp de C: cualquier programador que pruebe C como su primer idioma puede tener la tentación de escribir el siguiente código:

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

Dado que strcmp devuelve 0 , que se evalúa como false cuando las cadenas son iguales, lo que el programador principiante intentó hacer falló miserablemente y generalmente no entiende por qué al principio. Si 0 hubiera sido evaluado como true , esta función podría haberse usado en su expresión más simple, la anterior, al comparar la igualdad, y las verificaciones adecuadas de -1 y 1 se habrían realizado solo cuando necesario. Habríamos considerado el tipo de retorno como bool (en nuestra opinión, me refiero) la mayor parte del tiempo.

Además, introduzcamos un nuevo tipo, sign , que solo toma los valores -1 , 0 y 1 . Eso puede ser bastante útil. Imagina que hay un operador de la nave espacial en C ++ y lo queremos para std::string (bueno, ya existe compare función, pero el operador de la nave espacial es más divertido). La declaración sería actualmente la siguiente:

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

Si 0 se hubiera evaluado como true , el operador de la nave espacial ni siquiera existiría, y podríamos haber declarado operator== de esa manera:

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

Este operator== habría manejado la comparación de tres vías a la vez, y aún podría usarse para realizar la siguiente verificación mientras aún se puede verificar qué cadena es lexicográficamente superior a la otra cuando sea necesario:

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

Manejo de errores antiguos

Ahora tenemos excepciones, por lo que esta parte solo se aplica a los idiomas antiguos donde no existe tal cosa (por ejemplo, C). Si nos fijamos en la biblioteca estándar de C (y POSIX también), podemos ver con seguridad que muchas de las funciones devuelven 0 cuando tienen éxito y, de lo contrario, cualquier número entero. Lamentablemente he visto a algunas personas hacer este tipo de cosas:

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

Si pensamos en cómo pensamos en la programación, a menudo tenemos el siguiente patrón de razonamiento:

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

Si lo pensamos de nuevo, tendría sentido poner el único valor neutral, 0 , a yes (y así es como funcionan las funciones de C), mientras que todos los demás valores pueden estar ahí para resolver el problema. Muchos casos de no . Sin embargo, en todos los lenguajes de programación que conozco (excepto quizás algunos lenguajes esotéricos experimentales), yes se evalúa como false en una condición if , mientras que todos los casos no se evalúan como true . Hay muchas situaciones en las que "funciona" representa un caso, mientras que "no funciona" representa muchas causas probables. Si lo pensamos de esa manera, tener 0 evalúa a true y el resto a false hubiera tenido mucho más sentido.

Conclusión

Mi conclusión es esencialmente mi pregunta original: ¿por qué diseñamos idiomas donde 0 es false y los otros valores son true , teniendo en cuenta mis pocos ejemplos anteriores y tal vez algunos más que no pensé?

Seguimiento: Es bueno ver que hay muchas respuestas con muchas ideas y tantas razones posibles para que sea así. Me encanta lo apasionada que pareces al respecto. Originalmente hice esta pregunta por aburrimiento, pero ya que pareces muy apasionado, decidí ir un poco más lejos y preguntar sobre la justificación detrás de la opción booleana para 0 y 1 en Math.SE :)

    
pregunta Morwenn 15.05.2013 - 21:37

14 respuestas

97

0 es false porque ambos son elementos cero en semirings . Aunque son tipos de datos distintos, tiene sentido intuitivo convertirlos entre ellos porque pertenecen a estructuras algebraicas isomorfas.

  • 0 es la identidad para la suma y cero para la multiplicación. Esto es cierto para los enteros y los racionales, pero no números de coma flotante IEEE-754: 0.0 * NaN = NaN y 0.0 * Infinity = NaN .

  • false es la identidad de xor (⊻) booleano y cero para y (∧) booleano. Si los valores booleanos se representan como {0, 1}, el conjunto de enteros módulo 2, puede pensar en ⊻ como suma sin acarreo y ∧ como multiplicación.

  • "" y [] son identidades para concatenación, pero hay varias operaciones para las que tienen sentido como cero. La repetición es una, pero la repetición y la concatenación no se distribuyen, por lo que estas operaciones no forman un semiringuito.

Tales conversiones implícitas son útiles en programas pequeños, pero en general pueden hacer que los programas sean más difíciles de razonar. Solo una de las muchas ventajas y desventajas en el diseño del lenguaje.

    
respondido por el Jon Purdy 16.05.2013 - 05:47
74

Porque las matemáticas funcionan.

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

... insert many other examples here.

Tradicionalmente, los programas en C tienen condiciones como

if (someFunctionReturningANumber())

en lugar de

if (someFunctionReturningANumber() != 0)

porque se entiende bien el concepto de que cero es equivalente a falso.

    
respondido por el Robert Harvey 15.05.2013 - 21:52
38

Como han dicho otros, las matemáticas vinieron primero. Es por esto que 0 es false y 1 es true .

¿De qué matemáticas estamos hablando? álgebra booleana que data de mediados del siglo XIX, mucho antes de que aparecieran las computadoras digitales.

También podría decir que la convención surgió de la lógica proposicional , que es incluso más antigua que las álgebras booleanas. Esta es la formalización de muchos de los resultados lógicos que los programadores conocen y aman ( false || x es igual a x , true && x es igual a x y así sucesivamente).

Básicamente estamos hablando de aritmética en un conjunto con dos elementos. Piensa en contar en binario. Las álgebras booleanas son el origen de este concepto y su sustento teórico. Las convenciones de lenguajes como C son solo una aplicación directa.

    
respondido por el joshin4colours 15.05.2013 - 22:08
26

Pensé que esto tenía que ver con la "herencia" de la electrónica, y también con el álgebra booleana, donde

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

strcmp devuelve 0 cuando las cadenas son iguales tiene que ver con su implementación, ya que lo que realmente hace es calcular la "distancia" entre las dos cadenas. Ese 0 también se considera falso es solo una coincidencia.

devolver 0 en caso de éxito tiene sentido porque 0 en este caso se usa para significar sin error y cualquier otro número sería un código de error. Utilizar cualquier otro número para el éxito tendría menos sentido, ya que solo tiene un código de éxito único, mientras que puede tener varios códigos de error. Usted utiliza "¿Funcionó?" como la expresión de la declaración if y decir 0 = sí tendría más sentido, pero la expresión es más correcta "¿Algo salió mal?" y luego ves que 0 = no tiene mucho sentido. Pensar en false/true realmente no tiene sentido aquí, ya que en realidad es no error code/error code .

    
respondido por el Svish 16.05.2013 - 12:44
18

Como se explica en este artículo , los valores false y true no deben confundirse con los números enteros 0 y 1, pero puede identificarse con los elementos del campo Galois (campo finito) de dos elementos (consulte aquí ).

Un campo es un conjunto con dos operaciones que satisfacen ciertos axiomas.

Los símbolos 0 y 1 se usan convencionalmente para denotar las identidades aditivas y multiplicativas de un campo porque los números reales también son un campo (pero no uno finito) cuyas identidades son los números 0 y 1.

La identidad aditiva es el elemento 0 del campo, de manera que para todas las x:

x + 0 = 0 + x = x

y la identidad multiplicativa es el elemento 1 del campo, tal que para todas las x:

x * 1 = 1 * x = x

El campo finito de dos elementos tiene solo estos dos elementos, a saber, la identidad aditiva 0 (o false ) y la identidad multiplicativa 1 (o true ). Las dos operaciones de este campo son el XOR lógico (+) y el AND (*) lógico.

Nota. Si cambia las operaciones (XOR es la multiplicación y AND es la suma), entonces la multiplicación no es distributiva sobre la suma y ya no tiene un campo. En tal caso, no tiene ninguna razón para llamar a los dos elementos 0 y 1 (en cualquier orden). Tenga en cuenta también que no puede elegir la operación OR en lugar de XOR: no importa cómo interprete OR / AND como suma / multiplicación, la estructura resultante no es un campo (no todos los elementos inversos existen como lo requieren los axiomas de campo).

Respecto a las funciones C:

  • Muchas funciones devuelven un entero que es un código de error. 0 significa NO ERROR.
  • Intuitivamente, la función strcmp calcula la diferencia entre dos cadenas. 0 significa que no hay diferencia entre dos cadenas, es decir, que dos cadenas son iguales.

Las explicaciones intuitivas anteriores pueden ayudar a recordar la interpretación de los valores de retorno, pero es aún más fácil simplemente revisar la documentación de la biblioteca.

    
respondido por el Giorgio 16.05.2013 - 00:21
13

Debe considerar que los sistemas alternativos también pueden ser decisiones de diseño aceptables.

Shells: 0 estado de salida es verdadero, no cero es falso

El ejemplo de shells que tratan un estado de salida 0 como verdadero ya se ha mencionado.

$ ( 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 razón es que hay una manera de tener éxito, pero muchas formas de fallar, por lo que usar 0 como valor especial que significa "sin errores" es pragmático.

Ruby: 0 es como cualquier otro número

Entre los lenguajes de programación "normales", hay algunos valores atípicos, como Ruby, que tratan a 0 como un valor verdadero.

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

La justificación es que solo false y nil deben ser falsos. Para muchos novicios Ruby, es un gotcha. Sin embargo, en algunos casos, es bueno que 0 se trate como cualquier otro número.

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"

Sin embargo, tal sistema solo funciona en un idioma que puede distinguir los valores booleanos como un tipo separado de los números. En los primeros días de la computación, los programadores que trabajaban con lenguaje ensamblador o lenguaje de máquina en bruto no tenían tales lujos. Es probable que sea natural tratar a 0 como el estado "en blanco", y establecer un bit a 1 como indicador cuando el código detectó que algo sucedió. Por extensión, la convención desarrolló que el cero se trataba como falso y que los valores distintos de cero se trataron como verdaderos. Sin embargo, no tiene que ser así.

Java: los números no se pueden tratar como booleanos en absoluto

En Java, true y false son los únicos valores booleanos. Los números no son booleanos y ni siquiera se pueden convertir en booleanos ( Java Especificación de idioma, Sec. 4.2.2 ):

  

No hay conversiones entre los tipos integrales y el tipo boolean .

Esa regla simplemente evita la pregunta por completo: todas las expresiones booleanas deben escribirse explícitamente en el código.

    
respondido por el 200_success 10.04.2014 - 20:54
8

Antes de abordar el caso general, podemos discutir sus ejemplos de contador.

Comparaciones de cadenas

Lo mismo es válido para muchos tipos de comparaciones, en realidad. Tales comparaciones calculan una distancia entre dos objetos. Cuando los objetos son iguales, la distancia es mínima. Entonces, cuando la "comparación tiene éxito", el valor es 0. Pero en realidad, el valor de retorno de strcmp es no un booleano, es una distancia, y eso es lo que atrapa a los programadores que no saben que hacen if (strcmp(...)) do_when_equal() else do_when_not_equal() .

En C ++, podríamos rediseñar strcmp para devolver un objeto Distance , que reemplaza a operator bool() para devolver verdadero cuando 0 (pero luego sería mordido por un conjunto diferente de problemas). O en el plano C solo tiene una función streq que devuelve 1 cuando las cadenas son iguales, y 0 en caso contrario.

Código de salida de llamadas / programas API

Aquí te importa la razón por la que algo salió mal, ya que esto hará que las decisiones sean erróneas. Cuando las cosas tienen éxito, no quieres saber nada en particular, tu intención se realiza. El valor de retorno por lo tanto debe transmitir esta información. Es no un booleano, es un código de error. El valor de error especial 0 significa "sin error". El resto del rango representa errores significativos a nivel local con los que tiene que lidiar (incluido 1, que a menudo significa "error no especificado").

Caso general

Esto nos deja con la pregunta: ¿por qué los valores booleanos True y False se representan comúnmente con 1 y 0, respectivamente?

Bueno, además del argumento subjetivo de "se siente mejor así", aquí hay algunas razones (subjetivas también) en las que puedo pensar:

  • analogía del circuito eléctrico. La corriente está activada durante 1s, y desactivada durante 0s. Me gusta tener (1, Sí, Verdadero, Activado) juntos, y (0, No, Falso, Desactivado), en lugar de otra mezcla

  • inicializaciones de memoria. Cuando I memset(0) un montón de variables (ya sea ints, floats, bools) quiero que su valor coincida con los supuestos más conservadores. P.ej. mi suma es inicialmente 0, el predicado es Falso, etc.

Tal vez todas estas razones estén ligadas a mi educación: si me hubieran enseñado a asociar 0 con True desde el principio, buscaría lo contrario.

    
respondido por el Tibo 15.05.2013 - 23:23
6

Desde una perspectiva de alto nivel, estamos hablando de tres tipos de datos muy diferentes:

  1. Un booleano. La convención matemática en álgebra booleana es utilizar 0 para false y 1 para true , por lo que tiene sentido sigue esa convención. Creo que de esta manera también tiene más sentido intuitivamente.

  2. El resultado de la comparación. Esto tiene tres valores: < , = y > (observe que ninguno de ellos es true ). Para ellos tiene sentido utilizar los valores de -1, 0 y 1, respectivamente (o, más generalmente, un valor negativo, cero y un valor positivo).

    Si desea verificar la igualdad y solo tiene una función que realiza una comparación general, creo que debería hacerlo explícito usando algo como strcmp(str1, str2) == 0 . Encuentro que usar ! en esta situación es confuso, porque trata un valor no booleano como si fuera un booleano.

    Además, tenga en cuenta que la comparación y la igualdad no tienen que ser lo mismo. Por ejemplo, si ordena a las personas por fecha de nacimiento, Compare(me, myTwin) debería devolver 0 , pero Equals(me, myTwin) debería devolver false .

  3. El éxito o el fracaso de una función, posiblemente también con detalles sobre ese éxito o fracaso. Si estás hablando de Windows, este tipo se llama HRESULT y un valor distinto de cero no necesariamente indicar el fracaso. De hecho, un valor negativo indica un fracaso y un éxito no negativo. El valor de éxito es muy a menudo S_OK = 0 , pero también puede ser, por ejemplo, S_FALSE = 1 , u otros valores.

La confusión proviene del hecho de que tres tipos de datos lógicamente diferentes se representan como un solo tipo de datos (un número entero) en C y en algunos otros idiomas y que se puede usar un número entero en una condición. Pero no creo que tenga sentido redefinir booleano para que sea más sencillo utilizar algunos tipos no booleanos en condiciones.

También, considere otro tipo que se usa a menudo en una condición en C: un puntero. Allí, es natural tratar un punto NULL (que se representa como 0 ) como false . Por lo tanto, seguir su sugerencia también dificultaría el trabajo con los punteros. (Aunque, personalmente, prefiero comparar explícitamente los punteros con NULL , en lugar de tratarlos como booleanos).

    
respondido por el svick 15.05.2013 - 23:36
4

El cero puede ser falso porque la mayoría de las CPU tienen un indicador de CERO que se puede usar para bifurcar. Guarda una operación de comparación.

Veamos por qué.

Algunos psuedocode, ya que la audiencia probablemente no lea el ensamblaje

c- fuente bucle simple llama a wibble 10 veces

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

alguna asamblea simulada para eso

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- fuente otro bucle simple llama a wibble 10 veces

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

algún montaje ficticio para este 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  

algunos más c fuente

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

y la asamblea

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

¿Ves lo corto que es?

algunos más c fuente

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

y el ensamblaje (asumamos un compilador marginalmente inteligente que puede reemplazar == 0 sin comparación)

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

Ahora probemos una convención de true = 1

un poco más de fuente c     #define TRUE 1     int foo = TRUE;     if (foo == TRUE) wibble ()

y la asamblea

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

¿Ves lo corto que es el caso con un verdadero distinto de cero?

Las CPU realmente tempranas tenían pequeños conjuntos de indicadores adjuntos al Acumulador.

Para verificar si un > b o a = b generalmente toma una instrucción de comparación.

  • A menos que B sea CERO, en cuyo caso se establece el indicador CERO Implementado como un NOR lógico simple o todos los bits en el Acumulador.
  • O NEGATIVO en el que solo use el "bit de signo", es decir, el bit más significativo del Acumulador si está usando la aritmética de complemento de dos. (Sobre todo lo hacemos)

Vamos a reiterar esto. En algunas CPU más antiguas, no tenía que usar una instrucción de comparación para el acumulador igual a CERO, o el acumulador menor que cero.

¿Ahora ves por qué el cero podría ser falso?

Tenga en cuenta que este es un código psuedo y que ningún conjunto de instrucciones real se ve así. Si sabes ensamblaje, sabes que estoy simplificando mucho las cosas aquí. Si sabe algo sobre el diseño del compilador, no necesita leer esta respuesta. Cualquiera que sepa algo sobre el desenrollado de bucles o la predicción de ramas, la clase avanzada se encuentra en la sala 203.

    
respondido por el Tim Williscroft 16.05.2013 - 11:34
3

Hay muchas respuestas que sugieren que la correspondencia entre 1 y verdadero es necesaria por alguna propiedad matemática. No puedo encontrar ninguna propiedad de este tipo y sugerir que es una convención puramente histórica.

Dado un campo con dos elementos, tenemos dos operaciones: suma y multiplicación. Podemos mapear las operaciones booleanas en este campo de dos maneras:

Tradicionalmente, identificamos Verdadero con 1 y Falso con 0. Identificamos AND con * y XOR con +. Por lo tanto, OR es la adición de saturación.

Sin embargo, podríamos identificar fácilmente Verdadero con 0 y Falso con 1. Luego identificamos OR con * y XNOR con +. Por lo tanto, AND está saturando la suma.

    
respondido por el Neil G 16.05.2013 - 00:01
3

Curiosamente, el cero no siempre es falso.

En particular, la convención de Unix y Posix es definir EXIT_SUCCESS como 0 (y EXIT_FAILURE como 1). En realidad, ¡es incluso una convención C !

Entonces, para los shells Posix y exit (2) syscalls, 0 significa "exitoso "lo que intuitivamente es más cierto que falso.

En particular, el if de la shell quiere que un proceso devuelva EXIT_SUCCESS (que es 0) para seguir su rama "entonces".

En el Esquema (pero no en Common Lisp o en MELT ) 0 y nil (es decir, () en el Esquema) son verdaderos, ya que el único valor falso es #f

Estoy de acuerdo, ¡lo estoy haciendo!

    
respondido por el Basile Starynkevitch 28.07.2014 - 15:07
3

C se usa para la programación de bajo nivel cerca de hardware, un área en la que a veces es necesario cambiar entre operaciones lógicas y bitwise, en los mismos datos. Ser requerido para convertir una expresión numérica a booleana solo para realizar una prueba saturaría el código.

Puedes escribir cosas como:

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

en lugar de

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

En un ejemplo aislado, no es tan malo, pero tener que hacerlo será molesto.

Igualmente, converse operaciones. Es útil para el resultado de una operación booleana, como una comparación, producir un 0 o 1: supongamos que queremos establecer el tercer bit de una palabra en función de si modemctrl tiene el bit de detección del operador:

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

Aquí tenemos que tener != 0 , para reducir el resultado de la expresión biwise & a 0 o 1 , pero como el resultado es solo un número entero, nos ahorramos de tener que agregar algunos Molde molesto para convertir aún más booleano a entero.

A pesar de que la C moderna ahora tiene un tipo bool , aún conserva la validez de un código como este, tanto porque es bueno como debido a la ruptura masiva con la compatibilidad con versiones anteriores que sería causada de otra manera.

Otro ejemplo donde C es resbaladizo: probar dos condiciones booleanas como un conmutador de cuatro direcciones:

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

¡No podrías quitarle esto al programador de C sin luchar!

Por último, C a veces sirve como una clase de lenguaje ensamblador de alto nivel. En lenguajes ensambladores, tampoco tenemos tipos booleanos. Un valor booleano es solo un bit o un valor cero versus un valor distinto de cero en una ubicación de memoria o registro. Un cero entero, un cero booleano y la dirección cero se prueban de la misma manera en los conjuntos de instrucciones del lenguaje ensamblador (y quizás incluso en el punto flotante cero). El parecido entre C y el lenguaje ensamblador es útil, por ejemplo, cuando C se usa como el idioma de destino para compilar otro idioma (¡incluso uno que ha escrito con fuerza los booleanos!)

    
respondido por el Kaz 16.05.2013 - 03:16
0

Un valor booleano o de verdad solo tiene 2 valores. Verdadero y falso.

Estos no deben representarse como enteros, sino como bits (0 y 1).

Decir que cualquier otro entero junto a 0 o 1 no es falso es una declaración confusa. Las tablas de verdad tratan con valores de verdad, no con enteros.

A partir de un valor de verdad prospectivo, -1 o 2 romperían todas las tablas de verdad y cualquier lógica booleana asociada con ellas.

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

La mayoría de los idiomas generalmente tienen un tipo boolean que cuando se convierte a un tipo de número, como un entero, revela que falso se convierte como un valor entero de 0.

    
respondido por el Jon Raynor 15.05.2013 - 23:17
-6

En última instancia, estás hablando de romper el lenguaje central porque algunas API son malas. Las API de Crappy no son nuevas, y no puedes arreglarlas rompiendo el idioma. Es un hecho matemático que 0 es falso y 1 es verdadero, y cualquier lenguaje que no respete esto se rompe fundamentalmente. La comparación de tres vías es de nicho y no tiene ningún negocio, ya que su resultado se convierte implícitamente a bool , ya que arroja tres resultados posibles. Las antiguas API de C simplemente tienen un terrible manejo de errores, y también están bloqueadas porque C no tiene las características de lenguaje necesarias para no tener interfaces terribles.

Tenga en cuenta que no estoy diciendo que para idiomas que no tienen conversión implícita de enteros > booleanos.

    
respondido por el DeadMG 15.05.2013 - 21:52

Lea otras preguntas en las etiquetas