language agnostic - ¿VERDADERO siempre tuvo un valor distinto de cero?
language-agnostic boolean (22)
Tengo un compañero de trabajo que sostiene que VERDADERO solía definirse como 0 y todos los demás valores eran FALSOS. Podría jurar que en todos los lenguajes con los que he trabajado, si incluso se puede obtener un valor para un booleano, el valor de FALSE es 0. ¿TRUE solía ser 0? Si es así, ¿cuándo cambiamos?
En cualquier idioma en el que haya trabajado (volviendo al BASIC a finales de los 70), el falso se ha considerado 0 y el verdadero ha sido distinto de cero.
En idiomas como C no había ningún valor booleano, por lo que tenía que definir el suyo propio. ¿Podrían haber trabajado en una anulación de BOOL no estándar?
En su mayor parte, falso se define como 0 y verdadero no es cero. Algunos lenguajes de programación usan 1, algunos usan -1 y algunos usan cualquier valor distinto de cero.
Sin embargo, para los proyectiles de Unix, usan la convención opuesta.
La mayoría de los comandos que se ejecutan en un shell Unix son en realidad pequeños programas. Le devuelven un código de salida para que pueda determinar si el comando fue exitoso (un valor de 0), o si falló por alguna razón (1 o más, dependiendo del tipo de falla).
Esto se usa en los intérpretes sh / ksh / bash shell dentro de los comandos if / while / until para verificar las condiciones:
if command then # successful fi
Si el comando es exitoso (es decir, devuelve un código de salida cero), se ejecuta el código dentro de la instrucción. Usualmente, el comando que se usa es el [comando, que es un alias para el comando de prueba.
Es fácil confundirse cuando las declaraciones de retorno verdadero / falso de bash son al revés:
$ false; echo $?
1
$ true; echo $?
0
Incluso hoy en día, en algunos idiomas (Ruby, lisp, ...) 0 es cierto porque todo, excepto nil, es verdadero. Más a menudo 1 es verdadero. Eso es algo común, por lo que a veces se considera una buena práctica no confiar en que 0 sea falso, sino hacer una prueba explícita. Java requiere que hagas esto.
En lugar de esto
int x;
....
x = 0;
if (x) // might be ambiguous
{
}
Hacer es explícito
if (0 != x)
{
}
La cosa 0 / no-0 de la que su compañero de trabajo está confundido probablemente se esté refiriendo a cuando las personas usan valores numéricos como valor de retorno que indica éxito, no verdad (es decir, en scripts bash y algunos estilos de C / C ++).
El uso de 0 = éxito permite una precisión mucho mayor en la especificación de las causas de falla (por ejemplo, 1 = archivo perdido, 2 = extremidad faltante, etc.).
Como nota al margen: en Ruby, los únicos valores falsos son nulos y falsos. 0 es verdadero, pero no a diferencia de otros números. 0 es verdadero porque es una instancia del objeto 0.
Las llamadas al sistema en la biblioteca estándar C normalmente devuelven -1 en caso de error y 0 en caso de éxito. También la declaración if de Fotran calculada (y probablemente todavía lo hace) salta a uno de los tres números de línea dependiendo de la condición que evalúa a menos de, igual o mayor que cero.
ej .: IF (I-15) 10,20,10
probaría la condición de I == 15 saltando a la línea 20 si es verdadero (se evalúa a cero) y la línea 10 de lo contrario.
Sam tiene razón sobre los problemas de confiar en el conocimiento específico de los detalles de implementación.
Lo curioso es que depende del idioma con el que estés trabajando. En Lua es verdadero == cero interno para el rendimiento .. Lo mismo para muchas llamadas de sistema en C.
Los códigos DOS y de salida de las aplicaciones generalmente usan 0 para significar éxito y no cero para indicar fallas de algún tipo.
Los códigos de error de DOS son 0-255 y cuando se prueban usando la sintaxis ''errorlevel'' significan algo por encima o que incluye el valor especificado, de modo que lo siguiente coincide con 2 y arriba con el primer goto, 1 con el segundo y 0 (éxito) con el final !
IF errorlevel 2 goto CRS
IF errorlevel 1 goto DLR
IF errorlevel 0 goto STR
No estoy seguro, pero puedo decirles esto: los trucos basados en la naturaleza subyacente de VERDADERO y FALSO son propensos a error porque la definición de estos valores queda en manos del implementador del lenguaje (o, al menos, el especificador).
No puedo recordar que TRUE sea 0 . 0 es algo que un programador de C volvería a indicar el éxito, sin embargo. Esto puede confundirse con TRUE .
No siempre es 1 tampoco. Puede ser -1 o simplemente distinto de cero.
Para lenguajes sin un tipo booleano incorporado, la única convención que he visto es definir VERDADERO como 1 y FALSO como 0. Por ejemplo, en C, la instrucción if ejecutará la cláusula if si la expresión condicional evalúa a algo más que 0.
Incluso vi una vez un documento de directrices de codificación que decía específicamente no redefinir VERDADERO y FALSO. :)
Si está utilizando un lenguaje que tiene un booleano integrado, como C ++, las palabras clave true y false son parte del idioma y no debe confiar en cómo se implementan realmente.
Podría ser en referencia a un código de resultado de 0 que en la mayoría de los casos después de que se ha ejecutado un proceso, un código de resultado de 0 significaba, "Oye, todo funcionó bien, no hay problemas aquí".
Recuerdo haber hecho algo de programación VB en un formulario de acceso donde True era -1.
Recuerdo que PL / 1 no tenía clase booleana. Puede crear un bit y asignarle el resultado de una expresión booleana. Entonces, para usarlo, tenía que recordar que 1 era falso y 0 era verdadero.
Regla general:
Las conchas (DOS incluidas) usan "0" como "Sin error" ... no necesariamente verdadero.
Los lenguajes de programación utilizan un valor distinto de cero para denotar verdadero.
Dicho esto, si está en un idioma que le permite definir VERDADERO o FALSO, defínalo y siempre use las constantes.
Si nada más, los shells bash aún usan 0 para verdadero y 1 para falso.
Varias funciones en la biblioteca estándar C devuelven un entero ''código de error'' como resultado. Como noErr se define como 0, una comprobación rápida puede ser ''si es 0, está bien''. La misma convención llevada a un '''' código de resultado '''' del proceso de Unix; es decir, un número entero que dio alguna inidicación sobre cómo terminó un proceso determinado.
En las secuencias de comandos de shell de Unix, el código de resultado de un comando que acaba de ejecutarse está disponible, y se usa típicamente para indicar si el comando ''éxito'' o no, con 0 significa éxito, y cualquier otra cosa una condición específica de no éxito.
A partir de eso, todos los constructos de tipo prueba en scripts de shell usan ''success'' (es decir, un código de resultado de 0) para significar TRUE y cualquier otra cosa para decir FALSE.
En un plano totalmente diferente, los circuitos digitales suelen usar ''lógica negativa''. es decir, incluso si 0 voltios se llama ''binario 0'' y algún valor positivo (comúnmente + 5v o + 3.3v, pero hoy en día no es raro usar + 1.8v) se llama ''binario 1'', algunos eventos son ''afirmados'' por un pin dado va a 0. Creo que hay algunas ventajas resistentes al ruido, pero no estoy seguro de las razones.
Tenga en cuenta, sin embargo, que no hay nada "antiguo" o algún "tiempo de cambio" sobre esto. Todo lo que sé sobre esto se basa en las viejas convenciones, pero hoy son totalmente actuales y relevantes.
He oído hablar de y usé compiladores más antiguos donde verdadero> 0 y falso <= 0.
Esa es una de las razones por las que no desea usar if (puntero) o if (number) para comprobar cero, podrían evaluar false de forma inesperada.
Del mismo modo, he trabajado en sistemas donde NULL no era cero.
Trabajé en una empresa con una gran cantidad de código C antiguo. Algunos de los encabezados compartidos definían sus propios valores para VERDADERO y FALSO, y algunos sí tenían VERDADERO como 0 y FALSO como 1. Esto llevó a "guerras de la verdad":
/* like my constants better */
#undef TRUE
#define TRUE 1
#undef FALSE
#define FALSE 0
En el lenguaje C, antes de C ++, no existía el booleano. Los condicionales fueron hechos probando ints. Cero significaba falso y cualquier valor distinto de cero significaba verdadero. Entonces podrías escribir
if (2) {
alwaysDoThis();
} else {
neverDothis();
}
Afortunadamente C ++ permitió un tipo booleano dedicado.
El motor de base de datos de SQL Server optimiza el almacenamiento de columnas de bits. Si hay 8 o menos columnas de bits en una tabla, las columnas se almacenan como 1 byte. Si hay columnas de 9 a 16 bits, las columnas se almacenan como 2 bytes, y así sucesivamente. Los valores de cadena TRUE y FALSE se pueden convertir a valores de bit: TRUE se convierte en 1 y FALSE se convierte en 0. Convertir a bit promueve cualquier valor diferente de cero a 1.
Cada idioma puede tener 0 como verdadero o falso. Deje de usar palabras de uso numérico True Lol Or t y f Almacenamiento de 1 byte