Haga una pregunta sobre el recorrido del mapa stl

El número de recorridos de iterador en los dos métodos es el mismo, pero la eficiencia es diferente en STL. Antes++ devuelve una referencia y después++ devuelve un objeto temporal. Debido a que el iterador es una plantilla de clase, usarlo ++ devolverá un objeto temporal inútil, y ++ es una sobrecarga de función y el compilador no puede optimizarlo, por lo que cada vez que atraviesa un elemento, se crea y destruye un objeto temporal inútil.

Si no lo crees, puedes echar un vistazo a la biblioteca estándar de C++. Hay libros de texto que cumplen con el estándar C++. Excepto para necesidades especiales y tipos integrados, básicamente lo usa ++it para atravesar elementos, ya sea código fuente o libros de texto.

Las sobrecargas de operadores de tipo personalizado deben comportarse de manera similar a los operadores integrados, después de lo cual el incremento/decremento a menudo se denomina copia de su implementación.

Por ejemplo, normalmente se ve así:

Clase foo

{

Público:

foo &operator++(){ return ++ bar;}

foo operator++ (int)

{

foo tmp = * this//Crear objeto temporal★

++ *this; //Autoincremento antes de llamar

Devolver tmp //Devolver objeto temporal★

}

Privado:

int column;

}

Los dos pasos marcados con ★ arriba a veces son redundantes, como usar un iterador para atravesar un contenedor en STL, lo que provoca pérdidas innecesarias. en la eficiencia del programa.

Este también es un detalle que algunos programadores que migran de C a C++ a menudo pasan por alto, por eso se le llama el hábito de programación traído de C a C++.

C++ más eficiente

Ítem 6: Distinguir entre formas de prefijo y postfijo de operadores de incremento y decremento.

Explica en detalle los operadores pre/post incremento/decremento en C++ y los problemas de eficiencia causados ​​por la sobrecarga de C++. Esto es parte de esto:

Si eres el tipo de persona que se preocupa por la eficiencia, es posible que empieces a sudar la primera vez que veas la función de incremento postfix. La función debe crear un objeto temporal para su valor de retorno (consulte el elemento 19. La implementación anterior también crea un objeto temporal explícito (oldValue), que debe construirse y destruirse. No existe tal función temporal para las funciones de incremento de prefijo. Esto lleva a la quizás sorprendente conclusión de que, sólo por razones de eficiencia, los clientes de UPInt deberían preferir incrementos de prefijo a incrementos de postfijo a menos que realmente necesiten el comportamiento de los incrementos de postfijo. Seamos claros en esto.

Cuando se trata de tipos definidos por el usuario, se debe utilizar el prefijo incremental siempre que sea posible, ya que es inherentemente más eficiente. (tenga en cuenta esta frase).

Echemos otro vistazo a los operadores de incremento de prefijo y postfijo. Excepto por su valor de retorno, hacen lo mismo: incrementan un valor. Es decir, deberían hacer lo mismo. ¿Cómo se asegura de que el comportamiento de los incrementos de sufijo sea coherente con el comportamiento de los incrementos de prefijo? ¿Qué garantía tiene de que sus implementaciones no divergirán con el tiempo, tal vez como resultado de que diferentes programadores las mantengan y mejoren? A menos que siga los principios de diseño incorporados en el código anterior, no tendrá dicha garantía. El principio es que los incrementos y decrementos de postfijo deben implementarse de acuerdo con sus contrapartes de prefijo. Entonces sólo necesita mantener la versión del prefijo ya que la versión del sufijo se comportará automáticamente de manera consistente.