Tengo un compañero de trabajo que mantiene que TRUE 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?¿VERDADERO siempre ha tenido un valor distinto de cero?
Lo 0/no-0 su compañero de trabajo está confundido acerca probablemente se está refiriendo a cuando la gente usa los valores numéricos como valor de retorno que indica el éxito , no la verdad (es decir, en scripts bash y algunos estilos de C/C++).
El uso de 0 = success permite una precisión mucho mayor en la especificación de las causas de falla (por ejemplo, 1 = archivo faltante, 2 = miembro 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.
Si nada más, los shells bash todavía usan 0 para verdadero y 1 para falso.
Podría ser en referencia a un código de resultado de 0 que en la mayoría de los casos después de ejecutar un proceso, un código de resultado de 0 significaba, "Oye, todo funcionó bien, no hay problemas aquí".
Con la justificación de que no hay nada más que decir si funcionó, mientras que si falló, hay muchos códigos de retorno distintos de cero para indicar qué tipo de falla fue. – slim
ah ... bueno viejo COM – MagicKat
Y por lo tanto, el comando unix 'true' no hace más que emitir un código de retorno de 0. – Justsalt
En cualquier idioma en el que haya trabajado (volviendo a BASIC a finales de los 70), falso se ha considerado 0 y verdadero ha sido distinto de cero.
No estoy seguro, pero puedo decirle esto: los trucos que se basan en la naturaleza subyacente de VERDADERO y FALSO son propensos a error porque la definición de estos valores se deja en manos del implementador del lenguaje (o, en al menos, el especificador).
, en un lenguaje como perl donde hay una definición libre de verdad, es algo que aprendes no solo asignar sino amar. Pero en el ámbito de seguridad tipo de la mayoría de los lenguajes compilados, verdadero y falso son bastante estrictos en sus definiciones. – stephenbayer
Sí, pero se convierte en un problema potencial, incluso en el mismo idioma, si está convirtiendo compiladores, plataformas o simplemente actualizando a la última revisión de su idioma. Es por eso que defiendo ser independiente de la implementación a menos que esté muy seguro de su plataforma o que deba serlo. –
No recuerdo TRUE siendo 0. 0 es algo que un programador C volvería a indicar el éxito, sin embargo. Esto puede confundirse con TRUE.
Tampoco siempre es 1. Puede ser -1 o simplemente distinto de cero.
Para los idiomas sin un tipo booleano incorporado, la única convención que he visto es definir TRUE como 1 y FALSE como 0. Por ejemplo, en C, la sentencia if ejecutará la cláusula if si la expresión condicional evalúa a cualquier cosa que no sea 0.
Incluso vi una vez un documento de pautas de codificación que específicamente decía que no redefinía 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.
Creo que las palabras clave verdadero y falso tienen valores especificados por el estándar, por lo que PUEDE confiar en ellos. –
Varios idiomas, incluidas las versiones anteriores de VB, definen verdadero/falso como -1/0. Eso es para que las operaciones a nivel de bit y las operaciones lógicas hagan lo mismo. – user11318
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
{
}
cometen es explícita
if (0 != x)
{
}
Técnicamente en Java, las sentencias solo son válidas para expresiones booleanas y los enteros no se convierten en booleanos. En Java, true es verdadero y falso es falso y ninguno es un número. –
Java es mejor para anomolias booleanas –
Recuerdo hacer algunas programaciones VB en un formulario de acceso donde True era -1.
Creo que muchos sabores BÁSICOS evalúan cero como falso y cualquier cosa distinta de cero como verdadera, pero definen la constante False como 0 y la constante True como -1 (o todos los 1 en binario). –
La mayoría de los sabores BASIC no tienen operadores lógicos; todos los operadores son bit a bit. Por lo tanto, (NO 0) es -1 y las comparaciones se evalúan a -1 si es verdadero y 0 si es falso. – Artelius
En idiomas como C no había ningún valor booleano, por lo que tenía que definir uno propio. ¿Podrían haber trabajado en una anulación de BOOL no estándar?
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.
por ejemplo: SI (I-15) 10,20,10
habría probar para la condición de I == 15 salta a la línea 20 si es cierto (evalúa a cero) y la línea 10 de otra manera.
Sam tiene razón sobre los problemas de confiar en el conocimiento específico de los detalles de implementación.
Recuerdo que PL/1 no tenía ninguna 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.
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 Unix shell scripting, el código de resultado de un comando recién ejecutado está disponible, y se usa para indicar si el comando 'succeeded' o no, con 0 significa éxito y cualquier otra condición específica de no éxito.
A partir de eso, todas las construcciones tipo test en scripts de shell utilizan '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 utilizar '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" al respecto. Todo lo que sé sobre esto se basa en las viejas convenciones, pero hoy son totalmente actuales y relevantes.
DOS y los códigos de salida de las aplicaciones generalmente usan 0 para significar éxito y no cero para indicar la falla de algún tipo.
Los códigos de error DOS son 0-255 y cuando se prueban utilizando la sintaxis 'errorlevel' significan algo por encima o incluido el valor especificado, de modo que lo siguiente coincide con 2 y arriba con el primer goto, 1 con el segundo y 0 (éxito) a la final!
IF errorlevel 2 goto CRS
IF errorlevel 1 goto DLR
IF errorlevel 0 goto STR
Es fácil confundirse cuando los estados de verdadero/falso retorno del golpe son al revés:
$ false; echo $?
1
$ true; echo $?
0
En su mayor parte, falsa se define como 0, y la verdad es que no sea cero. Algunos lenguajes de programación usan 1, algunos usan -1 y algunos usan cualquier valor distinto de cero.
Sin embargo, para los cartuchos de Unix, utilizan 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 utiliza en los intérpretes de concha/bash sh/ksh dentro del si/mientras que/hasta que los comandos para comprobar las condiciones:
if command
then
# successful
fi
Si el comando es correcto (es decir, devuelve un código de salida cero), el código dentro de la declaración se ejecuta. Usualmente, el comando que se usa es el [comando, que es un alias para el comando de prueba.
Regla general:
Conchas (DOS incluido) utiliza "0" como "No error" ... no es necesariamente cierto.
Los lenguajes de programación usan distinto de cero para indicar verdadero.
Dicho esto, si estás en un lenguaje que permite definir su verdadero o falso, definirlo y siempre utilizar las constantes.
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.
En el lenguaje C, antes de C++, no existía ningún booleano. Los condicionales fueron hechos probando ints. Cero significaba falso y cualquier valor distinto de cero significaba verdadero. Entonces usted podría escribir
if (2) {
alwaysDoThis();
} else {
neverDothis();
}
Afortunadamente, C++ permitió un tipo booleano dedicado.
¿Alguien quiere explicar por qué esto fue rechazado? – DJClayworth
Porque reformuló lo dado en la pregunta. – Hogan
he oído hablar y utilizado compiladores anteriores donde la verdadera> 0, y falso < = 0.
Esa es una razón por la que no desea utilizar si (puntero) o si (número) para comprobar si hay cero , podrían evaluar como falso inesperadamente.
De manera similar, he trabajado en sistemas donde NULL no era cero.
Haha gracioso qué sobre 0.1 –
Trabajé en una empresa con una gran cantidad de código C antiguo. Algunas de las cabeceras compartidas definido sus propios valores de verdadero y falso, y algunos tienen efectivamente como VERDADERO y FALSO 0 como 1. Esto llevó a "guerras de la verdad": Motor de base
/* like my constants better */
#undef TRUE
#define TRUE 1
#undef FALSE
#define FALSE 0
Vota porque he sido mordido por eso en el pasado;) – Alaric
El SQL Server optimiza el almacenamiento de columnas de bit 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 en valores de bit: TRUE se convierte en 1 y FALSE se convierte en 0. Conversión a poco promueva cualquier valor distinto de cero a 1.
Cada lengua puede tener 0 como verdadero o falso Así que deje de usar palabras de uso numérico true Lol O t y f 1 octeto de almacenamiento
Me han mordido antes también ... –