¿Hay alguna razón técnica para usar> (<) en lugar de! = Cuando se incrementa en 1 en un bucle 'for'?

Casi nunca veo un forbucle como este:

for (int i = 0; 5 != i; ++i)
{}

¿Hay alguna razón técnica para usar >o en <lugar de !=cuando se incrementa en 1 en un forbucle? ¿O esto es más una convención?

while (time != 6:30pm) {
    Work();
}

Son las 6:31 pm ... Maldición, ¡ahora mi próxima oportunidad de ir a casa es mañana! :)

Esto para mostrar que la restricción más fuerte mitiga los riesgos y probablemente sea más intuitiva de entender.

No hay razón técnica. Pero existe una mitigación de riesgos, mantenibilidad y una mejor comprensión del código.

<o >son restricciones más fuertes que !=y cumplen exactamente el mismo propósito en la mayoría de los casos (incluso diría que en todos los casos prácticos).

Hay una pregunta duplicada aquí ; y una interesante respuesta .

Sí hay una razón Si escribe un bucle for simple (basado en índices antiguos) como este

for (int i = a; i < b; ++i){}

entonces funciona como se esperaba para cualquier valor de ay b(es decir, cero iteraciones cuando en a > blugar de infinito si lo hubiera usado i == b;).

Por otro lado, para iteradores escribirías

for (auto it = begin; it != end; ++it) 

porque cualquier iterador debe implementar un operator!=, pero no para cada iterador es posible proporcionar un operator<.

También basado en rango para bucles

for (auto e : v)

no son solo azúcar sofisticada, sino que reducen considerablemente las posibilidades de escribir código incorrecto.

Puedes tener algo como

for(int i = 0; i<5; ++i){
    ...
    if(...) i++;
    ...
}

Si su variable de bucle está escrita por el código interno, es i!=5posible que no rompa ese bucle. Esto es más seguro para verificar la desigualdad.

Edita sobre legibilidad. La forma de desigualdad se usa con mayor frecuencia. Por lo tanto, esto es muy rápido de leer ya que no hay nada especial que entender (la carga cerebral se reduce porque la tarea es común). Por lo tanto, es genial que los lectores hagan uso de estos hábitos.

Y por último pero no menos importante, esto se llama programación defensiva , lo que significa tomar siempre el caso más fuerte para evitar errores actuales y futuros que influyen en el programa.

El único caso en el que no se necesita programación defensiva es donde los estados han sido probados por condiciones previas y posteriores (pero luego, probar que esta es la más defensiva de toda la programación).

Yo diría que una expresión como

for ( int i = 0 ; i < 100 ; ++i )
{
  ...
}

es más expresivo de intención de lo que es

for ( int i = 0 ; i != 100 ; ++i )
{
  ...
}

El primero claramente dice que la condición es una prueba para un límite superior exclusivo en un rango; este último es una prueba binaria de una condición de salida. Y si el cuerpo del bucle no es trivial, puede que no sea evidente que el índice solo se modifica en la fordeclaración misma.

Los iteradores son un caso importante cuando usas la !=notación con mayor frecuencia :

for(auto it = vector.begin(); it != vector.end(); ++it) {
 // do stuff
}

De acuerdo: en la práctica, escribiría lo mismo confiando en range-for:

for(auto & item : vector) {
 // do stuff
}

pero el punto permanece: uno normalmente compara los iteradores usando ==o !=.

La condición de bucle es un bucle forzado invariante.

Supongamos que no miras el cuerpo del bucle:

for (int i = 0; i != 5; ++i)
{
  // ?
}

en este caso, usted sabe al comienzo de la iteración del ciclo que ino es igual 5.

for (int i = 0; i < 5; ++i)
{
  // ?
}

en este caso, sabe al comienzo de la iteración del bucle que ies menor que 5.

El segundo es mucha, mucha más información que el primero, ¿no? Ahora, la intención del programador es (casi con certeza) la misma, pero si está buscando errores, tener confianza al leer una línea de código es algo bueno. Y el segundo hace cumplir esa invariante, lo que significa que algunos errores que podrían morderlo en el primer caso simplemente no pueden suceder (o no causar corrupción de memoria, por ejemplo) en el segundo caso.

Sabes más sobre el estado del programa, al leer menos código, con < que con!= . Y en las CPU modernas, toman la misma cantidad de tiempo que ninguna diferencia.

Si ino se manipuló en el cuerpo del bucle, y siempre se aumentó en 1, y comenzó menos de5 , no habría diferencia. Pero para saber si fue manipulado, tendría que confirmar cada uno de estos hechos.

Algunos de estos hechos son relativamente fáciles, pero puede equivocarse. Sin embargo, verificar todo el cuerpo del asa es un dolor.

En C ++ puedes escribir un indexestipo tal que:

for( const int i : indexes(0, 5) )
{
  // ?
}

hace lo mismo que cualquiera de los dos forbucles anteriores , incluso hasta que el compilador lo optimiza al mismo código. Aquí, sin embargo, sabes que ino se puede manipular en el cuerpo del bucle, como se declara const, sin que el código corrompa la memoria.

Cuanta más información pueda obtener de una línea de código sin tener que comprender el contexto, más fácil será rastrear lo que va mal. <en el caso de los bucles enteros, le brinda más información sobre el estado del código en esa línea que la !=que brinda .

Si; OpenMP no paralela los bucles con la !=condición.

Puede suceder que la variable ise establezca en un valor grande y si solo usa el !=operador, terminará en un bucle sin fin.

Como puede ver en las otras numerosas respuestas, existen razones para usar <en lugar de! = Que ayudará en casos extremos, condiciones iniciales, modificación involuntaria del contador de bucle, etc.

Honestamente, sin embargo, no creo que puedas enfatizar la importancia de la convención lo suficiente. Para este ejemplo, será bastante fácil para otros programadores ver lo que está tratando de hacer, pero provocará una doble toma. Uno de los trabajos durante la programación es hacerlo lo más legible y familiar posible para todos, por lo que inevitablemente cuando alguien tiene que actualizar / cambiar su código, no se necesita mucho esfuerzo para darse cuenta de lo que estaba haciendo en diferentes bloques de código . Si viera a alguien usar !=, supondría que hay una razón por la que lo usaron en lugar de hacerlo <y si fuera un bucle grande, miraría todo el asunto tratando de averiguar qué hiciste que hizo que fuera necesario ... y eso es tiempo perdido.

Como ya dijo Ian Newson, no se puede recorrer de forma confiable una variable flotante y salir con ella !=. Por ejemplo,

for (double x=0; x!=1; x+=0.1) {}

en realidad se repetirá para siempre, porque 0.1 no puede representarse exactamente en coma flotante, por lo tanto, el contador pierde por poco 1. Con < esto termina.

(Sin embargo, tenga en cuenta que es básicamente un comportamiento indefinido si obtiene 0.9999 ... como el último número aceptado, lo que viola el supuesto menor que, o si ya sale a 1.0000000000000001).

Considero que el adjetivo "técnico" significa comportamiento / peculiaridades del lenguaje y efectos secundarios del compilador, como el rendimiento del código generado.

Para este fin, la respuesta es: no (*). El (*) es "consulte el manual de su procesador". Si está trabajando con algún sistema RISC o FPGA de caso extremo, es posible que deba verificar qué instrucciones se generan y cuánto cuestan. Pero si usted está usando casi cualquier arquitectura moderna convencional, entonces no hay diferencia significativa nivel de procesador de costo entre lt, eq, ney gt.

Si está utilizando un caso extremo se puede encontrar que !=requiere tres operaciones ( cmp, not, beq) frente a dos ( cmp, blt xtr myo). De nuevo, RTM en ese caso.

En su mayor parte, las razones son defensivas / endurecimiento, especialmente cuando se trabaja con punteros o bucles complejos. Considerar

// highly contrived example
size_t count_chars(char c, const char* str, size_t len) {
    size_t count = 0;
    bool quoted = false;
    const char* p = str;
    while (p != str + len) {
        if (*p == '"') {
            quote = !quote;
            ++p;
        }
        if (*(p++) == c && !quoted)
            ++count;
    }
    return count;
}

Un ejemplo menos ingenioso sería donde está utilizando valores de retorno para realizar incrementos, aceptando datos de un usuario:

#include <iostream>
int main() {
    size_t len = 5, step;
    for (size_t i = 0; i != len; ) {
        std::cout << "i = " << i << ", step? " << std::flush;

        std::cin >> step;
        i += step; // here for emphasis, it could go in the for(;;)
    }
}

Pruebe esto e ingrese los valores 1, 2, 10, 999.

Podrías evitar esto:

#include <iostream>
int main() {
    size_t len = 5, step;
    for (size_t i = 0; i != len; ) {
        std::cout << "i = " << i << ", step? " << std::flush;
        std::cin >> step;
        if (step + i > len)
            std::cout << "too much.\n";
        else
            i += step;
    }
}

Pero lo que probablemente querías era

#include <iostream>
int main() {
    size_t len = 5, step;
    for (size_t i = 0; i < len; ) {
        std::cout << "i = " << i << ", step? " << std::flush;
        std::cin >> step;
        i += step;
    }
}

También hay un sesgo hacia una convención <, porque a menudo se basa en ordenar en contenedores estándar operator<, por ejemplo, el hash en varios contenedores STL determina la igualdad al decir

if (lhs < rhs) // T.operator <
    lessthan
else if (rhs < lhs) // T.operator < again
    greaterthan
else
    equal

Si lhsy rhses una clase definida por el usuario que escribe este código como

if (lhs < rhs) // requires T.operator<
    lessthan
else if (lhs > rhs) // requires T.operator>
    greaterthan
else
    equal

El implementador tiene que proporcionar dos funciones de comparación. Así se <ha convertido en el operador favorito.

Hay varias formas de escribir cualquier tipo de código (generalmente), en este caso solo hay dos formas (tres si cuenta <= y> =).

En este caso, las personas prefieren> y <para asegurarse de que incluso si sucede algo inesperado en el bucle (como un error), no se repetirá infinitamente (MALO). Considere el siguiente código, por ejemplo.

for (int i = 1; i != 3; i++) {
    //More Code
    i = 5; //OOPS! MISTAKE!
    //More Code
}

Si usáramos (i <3), estaríamos a salvo de un bucle infinito porque coloca una restricción más grande.

Realmente es su elección si desea un error en su programa para cerrar todo o seguir funcionando con el error allí.

Espero que esto haya ayudado!

La razón más común para usar <es la convención. Más programadores piensan en bucles como este como "mientras el índice está dentro del rango" en lugar de "hasta que el índice llegue al final". Hay un valor que se apega a la convención cuando puedes.

Por otro lado, muchas respuestas aquí afirman que usar el <formulario ayuda a evitar errores. Yo diría que en muchos casos esto solo ayuda a ocultar errores. Si se supone que el índice de bucle alcanza el valor final y, en cambio, en realidad va más allá, entonces está sucediendo algo que no esperaba que puede causar un mal funcionamiento (o ser un efecto secundario de otro error). La <probable que retrasar el descubrimiento del error. los!= es más probable que conduzca a una parada, bloqueo o incluso un accidente, lo que ayudará a detectar el error antes. Cuanto antes se encuentre un error, más barato será repararlo.

Tenga en cuenta que esta convención es peculiar de la indexación de matrices y vectores. Al atravesar casi cualquier otro tipo de estructura de datos, usaría un iterador (o puntero) y buscaría directamente un valor final. En esos casos, debe asegurarse de que el iterador alcance y no sobrepase el valor final real.

Por ejemplo, si está recorriendo una cadena de C simple, generalmente es más común escribir:

for (char *p = foo; *p != '\0'; ++p) {
  // do something with *p
}

que

int length = strlen(foo);
for (int i = 0; i < length; ++i) {
  // do something with foo[i]
}

Por un lado, si la cadena es muy larga, la segunda forma será más lenta porque strlenes otro paso a través de la cadena.

Con un C ++ std :: string, usaría un bucle for basado en rango, un algoritmo estándar o iteradores, incluso si la longitud está disponible. Si está utilizando iteradores, la convención es usar en !=lugar de <, como en:

for (auto it = foo.begin(); it != foo.end(); ++it) { ... }

Del mismo modo, iterar un árbol o una lista o una eliminación generalmente implica buscar un puntero nulo u otro centinela en lugar de verificar si un índice permanece dentro de un rango.

Una razón para no usar esta construcción son los números de coma flotante. !=Es una comparación muy peligrosa para usar con flotadores, ya que rara vez se evaluará como verdadero incluso si los números se ven iguales. <o >elimina este riesgo.

Hay dos razones relacionadas para seguir esta práctica que tienen que ver con el hecho de que un lenguaje de programación es, después de todo, un lenguaje que será leído por los humanos (entre otros).

(1) Un poco de redundancia. En lenguaje natural, generalmente proporcionamos más información de la estrictamente necesaria, como un código de corrección de errores. Aquí, la información adicional es que la variable de bucle i(¿ve cómo utilicé la redundancia aquí? Si no sabía lo que significa "variable de bucle", o si olvidó el nombre de la variable, después de leer "variable de bucle i" tiene el nombre completo información) es inferior a 5 durante el ciclo, no solo diferente de 5. La redundancia mejora la legibilidad.

(2) Convención. Los idiomas tienen formas estándar específicas de expresar ciertas situaciones. Si no sigue la forma establecida de decir algo, aún se lo entenderá, pero el esfuerzo para el destinatario de su mensaje es mayor porque ciertas optimizaciones no funcionarán. Ejemplo:

No hables de la mezcla caliente. ¡Solo ilumina la dificultad!

La primera oración es una traducción literal de un idioma alemán. El segundo es un idioma común en inglés con las palabras principales reemplazadas por sinónimos. El resultado es comprensible, pero lleva mucho más tiempo comprenderlo que esto:

No andes por las ramas. ¡Solo explica el problema!

Esto es cierto incluso en el caso de que los sinónimos utilizados en la primera versión se ajusten mejor a la situación que las palabras convencionales en el idioma inglés. Fuerzas similares están en vigor cuando los programadores leen el código. Esta es también la razón 5 != iy 5 > ison formas extrañas de expresarlo a menos que esté trabajando en un entorno en el que es estándar intercambiar lo más normal i != 5y i < 5de esta manera. Tales comunidades dialectales existen, probablemente porque la consistencia hace que sea más fácil recordar escribir en 5 == ilugar de ser natural pero propenso a errores i == 5.

El uso de comparaciones relacionales en tales casos es más un hábito popular que cualquier otra cosa. Ganó su popularidad en los tiempos en que consideraciones conceptuales como las categorías de iteradores y su comparabilidad no se consideraban de alta prioridad.

Yo diría que uno debería preferir usar comparaciones de igualdad en lugar de comparaciones relacionales siempre que sea posible, ya que las comparaciones de igualdad imponen menos requisitos a los valores que se comparan. Ser EqualityComparable es un requisito menor que ser LessThanComparable .

Otro ejemplo que demuestra la aplicabilidad más amplia de la comparación de igualdad en tales contextos es el enigma popular con la implementación de unsignediteración hasta 0. Se puede hacer como

for (unsigned i = 42; i != -1; --i)
  ...

Tenga en cuenta que lo anterior es igualmente aplicable a la iteración con signo y sin signo, mientras que la versión relacional se desglosa con tipos sin signo.

Además de los ejemplos, donde la variable de bucle cambiará (no intencionalmente) dentro del cuerpo, existen otras razones para usar los operadores más pequeños o más grandes que:

• Las negaciones hacen que el código sea más difícil de entender
• <o >es solo un char, pero !=dos

Además de las diversas personas que han mencionado que mitiga el riesgo, también reduce la cantidad de sobrecargas de funciones necesarias para interactuar con varios componentes estándar de la biblioteca. Como ejemplo, si desea que su tipo se pueda almacenar en std::set, o se use como una clave std::map, o se use con algunos de los algoritmos de búsqueda y clasificación, la biblioteca estándar generalmente se usa std::lesspara comparar objetos, ya que la mayoría de los algoritmos solo necesitan un orden débil estricto . Por lo tanto, se convierte en un buen hábito usar las <comparaciones en lugar de las !=comparaciones (donde tiene sentido, por supuesto).

No hay problema desde una perspectiva de sintaxis, pero la lógica detrás de esa expresión 5!=i no es sólida.

En mi opinión, usar !=para establecer los límites de un bucle for no es lógicamente correcto porque un bucle for aumenta o disminuye el índice de iteración, por lo que configurar el bucle para iterar hasta que el índice de iteración se salga de los límites (!= a algo) no es un Implementación adecuada.

Se va a trabajar, pero es propenso al mal comportamiento ya que el manejo de los datos límite se pierde cuando se utiliza !=para un problema incrementales (lo que significa que usted sabe desde el principio si vale incrementos o decrementos), por eso en lugar de !=la <>>==>se utilizan.