c++ - relacionales - ¿Está bien usar "y", "o" etc. en lugar de "&&", "||"?
operadores || (8)
Estoy acostumbrado a las palabras clave and y or en C ++. Siempre los he usado y escribirlos es rápido y cómodo para mí. Una vez que escuché que estos alias no son estándar y es posible que no funcionen en todos los compiladores. Pero no estoy seguro de eso, realmente no sé si es verdad.
Supongamos que le doy mi código a alguien, ¿tendrá problemas para compilarlo?
¿Está bien cuando uso and , or lugar de && , || ? ¿O son estas palabras clave realmente no estándar?
PSI utiliza el compilador MinGW.
De hecho, son estándar en C ++, como se define en la norma ISO 14882: 2003 C ++ estándar 2.5 / 2 (y, de hecho, como se define en la edición de 1998 de la norma). Tenga en cuenta que están incorporados en el propio idioma y no requieren que incluya un archivo de encabezado de algún tipo.
Sin embargo, rara vez se utilizan, y todavía tengo que ver el código de producción que realmente utiliza los tokens alternativos. La única razón por la que existen los tokens alternativos en primer lugar es porque estos caracteres en algunos teclados (especialmente los que no son QWERTY) eran inexistentes o torpes para escribir. Todavía está en el estándar de compatibilidad hacia atrás.
Aunque son estándar, te recomiendo que no los uses. Los tokens alternativos requieren más caracteres para escribir, y la distribución del teclado QWERTY ya tiene todos los caracteres necesarios para escribir el código C ++ sin tener que usar los tokens alternativos. Además, lo más probable es que desconciertan a los lectores de su código.
2.5 / 2 fichas alternativas
En todos los aspectos del lenguaje, cada token alternativo se comporta igual, respectivamente, como token primario, excepto por su ortografía. El conjunto de fichas alternativas se define en la Tabla 2.
Table 2 - alternative tokens +--------------+-----------+ | Alternative | Primary | +--------------+-----------+ | <% | { | | %> | } | | <: | [ | | :> | ] | | %: | # | | %:%: | ## | | and | && | | bitor | | | | or | || | | xor | ^ | | compl | ~ | | bitand | & | | and_eq | &= | | or_eq | |= | | xor_eq | ^= | | not | ! | | not_eq | != | +--------------+-----------+
Estas palabras clave SON estándar y se describen en la sección 2.5 del estándar. La tabla 2 es una tabla de estos "tokens alternativos". Puedes usarlos todo lo que quieras, aunque todos te odiarán si lo haces.
La Sección 2.5 de la norma ISO / IEC 14882: 1998 (la norma C ++ original) dice:
§2.5 fichas alternativas [lex.digraph]
1 Se proporcionan representaciones de token alternativas para algunos operadores y signos de puntuación 16) .
2 En todos los aspectos del lenguaje, cada token alternativo se comporta igual, respectivamente, como token primario, excepto por su ortografía 17) . El conjunto de fichas alternativas se define en la Tabla 2.
16) Estos incluyen "dígrafos" y palabras reservadas adicionales. El término "dígrafo" (token que consta de dos caracteres) no es perfectamente descriptivo, ya que uno de los tokens de preprocesamiento alternativos es%:%: y, por supuesto, varios tokens primarios contienen dos caracteres. No obstante, los tokens alternativos que no son palabras clave léxicas se conocen coloquialmente como "dígrafos".
17) Por lo tanto, los valores "encadenados" (16.3.2) de [y <: serán diferentes, manteniendo la ortografía de origen, pero los tokens pueden intercambiarse libremente.
Table 2—alternative tokens _______________________________________________________________________________ alternative primary | alternative primary | alternative primary <% { | and && | and_eq &= %> } | bitor | | or_eq |= <: [ | or || | xor_eq ^= :> ] | xor ^ | not ! %: # | compl ~ | not_eq != %:%: ## | bitand & | _______________________________________________________________________________
No hay discusión sobre ''si incluyes algún encabezado'' (aunque en C, necesitas #include <iso646.h> ). Cualquier implementación que no admita las palabras clave o los dígrafos no cumple con la edición de 1998, y mucho menos con las ediciones posteriores, del estándar C ++.
Obviamente en lo que respecta a la compatibilidad con versiones anteriores, las palabras clave "y / o" no son el problema. Yo creo que ellos son el nuevo estándar. Es solo que los programadores antiguos no entienden que algún noob podría tener que ser capaz de leer el código y no querer buscar lo que significa &&. ¡De nuevo, si un departamento de TI vale la pena, hará que los programadores se ajusten a los estándares de la empresa! Esa es mi creencia de que (y / o) son estándares futuristas y reales posibles hacia el futuro. && es compatible con versiones anteriores (pun) (y / o).
Siempre he desordenado ^ (xor) y los operadores ~ (dos complementos). Con los tokens alternativos (que creo que deberían ser los principales) no hay duda sobre lo que hacen, sí, estoy de acuerdo con los carteles anteriores de que los textos son mucho más descriptivos.
Hay otro posible error al usar los digraphs, es posible olvidar uno de los caracteres en ||, && que causará errores sutiles y comportamientos extraños. Con los operadores textuales, es mucho más difícil cometer tal error.
Creo que lo que mencioné anteriormente son argumentos válidos para mejorar la seguridad y claridad del código. La mayoría de los programadores de C ++ DEBERÍAN, en mi opinión, tratar de acostumbrarse a los operadores textuales a favor de los antiguos crípticos.
Me sorprende que tan pocos programadores sepan de ellos. Estos operadores deberían haber tomado el control hace mucho tiempo como lo veo.
Son estándar en el nuevo estándar c ++ 0x. Los compiladores modernos y actualizados deben reconocerlos, aunque no creo que estén obligados a hacerlo todavía. Lo que sea que flote tu bote, supongo.
Wow, he estado usando y mirando muchos ejemplos de código C ++ durante años ... y nunca, hasta ahora, los conocí, así que supongo que eso significa que la mayoría de la gente no los usa. Por lo tanto, en aras de la coherencia (si planea trabajar en proyectos de grupo, etc.) probablemente sea mejor hacer un hábito de usar && y ||.
son C ++ estándar, pero con compiladores más antiguos y posiblemente también con MSVC 10.0 (no lo he comprobado) es posible que tenga que incluir un encabezado especial, [isosomethingsomething.h]
saludos & hth.,