Las versiones escritas de los operadores lógicos


94

Este es el único lugar que he visto en mi vida and, ory notque figuran como operadores reales en C ++. Cuando escribí un programa de prueba en NetBeans, obtuve el subrayado rojo como si hubiera un error de sintaxis y pensé que el sitio web estaba mal, pero es NetBeans el que está mal porque se compiló y ejecutó como se esperaba.

Puedo ver !que me favorecen, notpero la legibilidad de and&& orparece mayor que la de sus hermanos gramaticales. ¿Por qué existen estas versiones de los operadores lógicos y por qué aparentemente nadie las usa? ¿Es esto C ++ verdaderamente válido o algún tipo de compatibilidad con C que se incluyó con el lenguaje?


4
\ me Reescribe todo su código
Expiación limitada

2
en el espíritu del "código limpio", personalmente recomendaría eliminar el hábito de escribir ||y &&, tal vez, incluso !a veces. Las palabras siempre son mejores que el "ruido de línea", sin mencionar la posible confusión con los operadores de manipulación de bits.
Ichthyo

2
@Ichthyo Eso no siempre es correcto. Es mucho más rápido leer muchos símbolos y conocer su significado que leer muchas palabras.
Vallentin

lo que es más claro para un lector humano depende de la "Gestalt". A veces, un símbolo puede ser más claro que un término confuso, pero en este caso no lo es. Y, las palabras simples del idioma inglés son mucho más universales que algunos símbolos especiales extraños de un lenguaje de programación algo extraño ...
Ichthyo

3
La ironía de decir que andes más legible y luego escribir " and&& or" sin embargo :)
Ivan Vergiliev

Respuestas:


111

Se originaron en C en el encabezado <iso646.h>. En ese momento, había teclados que no podían escribir los símbolos requeridos para &&(por ejemplo), por lo que el encabezado contenía #definelos que los ayudarían a hacerlo, definiendo (en nuestro ejemplo) andser &&. Por supuesto, a medida que pasaba el tiempo, esto se hizo menos utilizado.

En C ++, se convirtieron en lo que se conoce como tokens alternativos . No es necesario incluir nada para usar estos tokens en un compilador compatible (como tal, la versión C ++ - ified del encabezado C <ciso646>, está en blanco). Los tokens alternativos son como los tokens normales, excepto por la ortografía. Entonces, durante el análisis andes exactamente lo mismo que &&, es solo una forma diferente de deletrear lo mismo.

En cuanto a su uso: debido a que rara vez se usan, su uso suele ser más sorprendente y confuso que útil. Estoy seguro de que si fuera normal, serían mucho más fáciles de leer, pero la gente está tan acostumbrada &&y ||cualquier otra cosa se distrae.

EDITAR: Sin embargo, he visto un ligero aumento en su uso desde que publiqué esto. Todavía los evito.


Entonces, ¿la interpretación de estos tokens alternativos es solo una característica del compilador o está en la especificación de C ++?
defectuosohalt

2
@Kavon: se especifica en la sección 2.5 del estándar; es una característica del idioma.
GManNickG

15
Personalmente, creo que son mucho mejores ... pero luego estoy sesgado con Python. No sé por qué algunas personas piensan que si no está distorsionado no es código ...
Matthieu M.

¿Entonces estos no son válidos en C sin incluir ese archivo de encabezado? Me sorprende que no todos los utilicen; hacen que Python sea mucho más legible.
endolito

1
Al menos a Visual Studio 2015 CTP 6 no le gustó mi oro notsin incluir el encabezado.
usr1234567

19

Existen para la usabilidad (soporte de caracteres en los sabores de teclado / pantalla) y la legibilidad general, pero hay otra razón que hoy en día es más pronunciada. Casi ninguna de las respuestas aquí , aquí , o incluso la respuesta principal aquíExplique la razón principal por la que muchos de nosotros preferimos las versiones de palabras a las versiones de símbolos (y una razón principal por la que otros idiomas las usan): errores. Las diferencias entre las versiones de palabras son muy visibles. Las diferencias entre las versiones de los símbolos son notablemente menores, hasta el punto de tentar a los errores en un grado comparativamente mucho mayor: "x | y" no es "x || y", pero cuando se incluye en una expresión más amplia, muchos de nosotros pierda la diferencia. Es similar a la mezcla accidental común del operador de asignación versus igualdad. Por esta razón, me deshice de las versiones de símbolos (no fue fácil) a favor de las versiones de palabras. Prefiero que alguien haga una doble toma de ellos debido a nuestro amor por las cosas viejas que tentar a los insectos.


4
Desafortunadamente, en Visual Studio (a partir de VS2013), debe establecer una opción de compilador específica ( /Za) para admitir las palabras clave alternativas (consulte stackoverflow.com/a/555524/368896 ). Eso presumiblemente también tiene otros impactos. Entonces, en Visual Studio, no es necesariamente seguro seguir este consejo.
Dan Nissenbaum

FWIW /: como pongo espacios alrededor de los operadores, x | yes visualmente distinto (en fuentes monoespaciadas) de x || y, pero encuentro que, !por ejemplo, es if (!f(xyz) && ...más fácil pasar por alto que if (not f(xyz) && ....
Tony Delroy

@Tony D cuando pone espacios alrededor de los operadores, esa es su convención privada y no es obvia para el lector. Pero el uso de palabras en lenguaje natural como and, ory noten una expresión booleana, en realidad mejora la legibilidad y resalta la distinción a las manipulaciones de bits. Por lo tanto, en mi humilde opinión, deberíamos considerar cambiar nuestros amados viejos hábitos para mejorar ...
Ichthyo

@DanNissenbaum Encontré esta opción con el nombre C / C ++> Idioma> Deshabilitar extensiones de idioma , por lo que es relativamente seguro esperar efectos secundarios;)
Wolf

6
¿Sabes cuántos errores de Python se han introducido porque las palabras andy el orsesgo de pensamiento de las personas sobre cómo deberían funcionar? Por ejemplo, en if (a == b or c)lugar de if (a == b || a == c), algo como esto aparece casi todos los días aquí en StackOverflow. Los símbolos abstractos que están desconectados del idioma inglés reducen estos errores.
Mark Ransom

10

En C ++, son palabras clave reales. En C, son macros definidas en <iso646.h>. Consulte http://web.archive.org/web/20120123073126/http://www.dinkumware.com/manuals/?manual=compleat&page=iso646.html .


6
Técnicamente, son tokens alternativos, no palabras clave. :)
GManNickG

2
@GMan: +1 Buena llamada, sin embargo, la página de Dinkumware los llama palabras clave, así que supongo que no les importó demasiado la distinción.
Chris Jester-Young


Entonces, ¿MSVC los admite desde el primer momento en C ++ pero no en C?
rwst

1
@rwst No puedo comentar sobre MSVC específicamente, pero si implementa los estándares C ++ y C fielmente, entonces ese será el caso. Ver también: stackoverflow.com/questions/2376448/…
Chris Jester-Young

2

andy &&son funcionalmente iguales en C ++. Los operadores andy orson C ++ verdaderamente válidos y forman parte del estándar del lenguaje.

Para más detalles sobre otras respuestas con un ejemplo concreto, hay otra razón, además de sólo "legibilidad" preferir andmás &&. Deletrear "y" explícitamente cuando se trata de un Y lógico elimina la posibilidad de errores sutiles.

Considera esto:

int x = 3;
int y = 4;

// Explicitly use "and"
if (x and y) {
    cout << "and: x and y are both non-zero values" << endl;
}

// Using "&&"
if (x && y) {
    cout << "&&: x and y are both non-zero values" << endl;
}

// Oops! I meant to type "&&"!
if (x & y) {
    cout << "&: x and y are both non-zero values" << endl;
}
else {
    cout << "How did I get here?" << endl;
}

Las tres sentencias if se compilarán, ¡pero la última significa algo completamente diferente y no intencionado!

Si siempre usa andcuando se refiere a un AND lógico, nunca podrá escribir accidentalmente un solo "&" y hacer que su código se compile correctamente y se ejecute con resultados misteriosos.

Otro buen ejercicio: intente omitir un carácter de "y" por accidente y vea qué sucede. ;)


1
Esta no es realmente una respuesta a la pregunta. Solo estás diciendo que lo que sientes es más legible. El OP preguntó cómo funcionan las versiones escritas, no cuáles son mejores. Y alguien más ya señaló lo mismo que estás tratando de hacer.
Nicol Bolas

No es que realmente proporcione más información útil, pero agregaré " andy &&son funcionalmente idénticos" a la respuesta ... Y si lees mi respuesta, verás que estoy diciendo que NO se trata de legibilidad;)
tjwrona1992
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.