Incrementando iteradores: ¿es más eficiente que él ++?

Question

Duplicar posible:
Is there a performance difference between i++ and ++i in C++?

Estoy escribiendo un programa en el que un repetidor se utiliza para recorrer un std :: vector. Alguien me dijo que hacer + + en la declaración for lleva a un código más eficiente. En otras palabras, están diciendo que:

for (vector<string>::iterator it=my_vector.begin(); it != my_vector.end(); ++it) 

corre más rápido que

for (vector<string>::iterator it=my_vector.begin(); it != my_vector.end(); it++) 

es esto cierto? Si lo es, ¿cuál es el motivo de la mejora de la eficiencia? Todo lo que hace ++/++ es mover el iterador al siguiente elemento en el vector, ¿no es así?

Answer 1

A veces sí. Con algunos se optimizará y será lo mismo. Para std :: vector <> (y otros std-iterators) lo más probable es que se optimice para que sea el mismo.

Answer 2

Sí. Por lo que recuerdo, ++ es más eficiente que ++, porque ++ crea un objeto temporal, mientras que ++ no lo hace.

Answer 3

sí ++ es más eficiente porque ++ necesita devolver una copia del objeto y luego incrementarse.

Answer 4

La razón detrás de que el preincremento sea más rápido es que el incremento posterior tiene que hacer una copia del valor anterior para devolver. Como GotW #2 lo expresó, "El preincremento es más eficiente que el postincremento, porque para postincremento, el objeto debe incrementarse y luego devolver un valor temporal que contiene su valor anterior. Tenga en cuenta que esto es cierto incluso para construcciones internas como int".

GotW #55 proporciona la forma canónica de postincremento, lo que muestra que tiene que ver preincremento además de algunos trabajos más:

T T::operator++(int) 
{ 
    T old(*this); // remember our original value 
    ++*this;  // always implement postincrement 
        // in terms of preincrement 
    return old;  // return our original value 
} 

Como otros han señalado, es posible que algunos compilador para optimizar esta distancia, en algunos casos, pero si no está utilizando el valor de retorno, es una buena idea no confiar en esta optimización. Además, es probable que la diferencia de rendimiento sea muy pequeña para los tipos que tienen constructores de copia triviales, aunque creo que el uso de preincremento es un buen hábito en C++.

Answer 5

Existe la posibilidad de que ++ cree una copia temporal.

Además, en C++, existe la posibilidad de que alguien haya sobrecargado el operador postincrement.

Ambas cosas pueden disminuir el rendimiento vs preincremento. Ninguna de las dos tendrá importancia en la práctica. La mayoría de los compiladores optimizarán la copia temporal, en particular, ya que no hay efectos secundarios en la tercera expresión de su bucle For.

Answer 6

Es poco probable que haga una diferencia para un vector.

En general, ++it es muy poco probable que sea más lento que it++ (suponiendo una aplicación sensata, si están sobrecargados), y sólo podría ser más rápido. El motivo es que si la clase de iterador en sí misma es compleja, entonces porque it++ tiene que devolver el valor antes de que it se incremente, la implementación generalmente hará una copia.

Los iteradores vectoriales son probablemente "solo punteros" (en construcciones optimizadas sin depuración), y ambos operator++ s estarán en línea. Como el valor de retorno no se utiliza, la copia generalmente se eliminará. Por lo tanto, no hará ninguna diferencia. Tengo la costumbre de escribir ++it porque:

1) Algún día podría hacer una diferencia, para algún tipo de iterador, y no quiero tener que hacer algo especial para ese tipo.

2) Personalmente creo que el operador del prefijo expresa más claramente la intención: "incrementarlo", en lugar de "usarlo y luego incrementarlo".

Answer 7

se ++ realiza las siguientes operaciones:

1. crear una copia de de ella
2. incremento que
3. devolverá el original (no incrementado) que

++ realiza la siguientes operaciones:

1. incremento que
2. retorno que

Porque ++ crea una copia, puede decirse que es "más lento". Sin embargo, cualquier compilador decente optimizará esta diferencia para la mayoría de los tipos definidos. Para algunos tipos definidos por el usuario, puede ser más rápido.