No había procesado esto bien y la verdad nunca habría pensado que eso fuera así ya que yo creía que el operador que mantiene una dependencia es el postfijo que necesita usar otro registro (como se veía en los ensambladores de MAFUS y engel lex) para almacenar el valor todavía sin incrementar. Sin embargo, me parece curioso aunque se me escape de las manos el entenderlo.

Entonces para resumir: el estándar C++17 especifica que primero se evalúa la parte de la derecha y después la de la izquierda pero los efectos colaterales siguen sin estar definidos; a diferencia de Java que evalúa de izquierda a derecha y especifica que los efectos colaterales se resuelven inmediatamente después.

Es posible que algunas personas lo vean como una pérdida de tiempo pero me interesaba saber cuáles eran las diferencias entre estos dos lenguajes en este aspecto y al final parece que lo estoy consiguiendo con las aportaciones del resto de miembros y sobre todo con las explicaciones de RayR, que agradezco.
También es verdad que consultando las especificaciones de cada lenguaje acabaría antes pero entre que no sé dónde localizarlas ni hasta donde llegaría a entender pues... supongo que dentro de mis posibilidades haré lo que pueda y en este caso lo que podía hacer eran pruebas para intentar sacar alguna conclusión de forma práctica. He visto que no llegaba a nada con pruebas pues entonces he probado en el foro.
Si todos nos tuviésemos que buscar la vida yendo a las fuentes oficiales de cada tema, no servirían de nada los foros porque lo que cualquiera pueda afirmar en un foro tendrá que estar apoyado por algún tipo de documentación oficial.

Es que de ese código no se puede sacar ninguna conclusión. Primero, porque fue compilado sin optimizaciones, y eso por sí sólo lo descarta para este objetivo, ya que el código generado no es realista, y los compiladores hacen cosas que normalmente no harían, por ejemplo, pueden tomar ciertas decisiones que empeoran el rendimiento, pero facilitan la depuración, etc. Además, el ensamblador que pusieron sólo aplica para GCC, pues si compilamos el código con Visual C++, genera la misma cantidad de instrucciones para ambas. Y es que GCC no necesitaba generar 4 instrucciones para el int n = b++. Pudo haber hecho simplemente esto:

        mov     eax, DWORD PTR [rbp-8]
        add     DWORD PTR [rbp-8], 1
        mov     DWORD PTR [rbp-16], eax

Y ya está. No hay ninguna razón que obligue a que la forma postfija requiera más instrucciones. Lo que vimos en el ejemplo original sin optimizar es simplemente lo que GCC decicidió hacer (por las razones que sea) en este caso concreto. Pero aún en el caso en el que GCC generó 4 instrucciones, usó lea en la suma. Esa instrucción no es para operaciones aritméticas, pero es una "optimización" común usarla para eso. Lo pongo entre comillas porque depende del procesador, pero en algunos casos, esa operación podría salir casi "gratis" (se podría ejecutar en paralelo con otras) por lo que, para efectos de tiempo de ejecución, sería prácticamente como si no existiera. Como había dicho antes, contar instrucciones no es suficiente.

De cualquier forma, nunca se debería un ejemplo tan simple, ya que los compiladores son bastante inteligentes (casi siempre) y no traducen instrucción por instrucción sino que analizan bloques de código y a partir de ahí deciden. Por eso es muy importante el uso, el contexto, sobre todo porque los compiladores de C/C++ tienen permitido hacer muchísimas modificaciones a nuestro código, siempre que no modifiquen su comportamiento observable. Porque si compilamos el código original de MAFUS con optimizaciones, como es debido, veremos que tampoco es de utilidad, ya que todos los compiladores modernos se darán cuenta de que no hace nada, así que eliminarán todas las instrucciones y simplemente harán que main retorne 0.


Lo que puse de la dependencia tómalo con muchas reservas, ya que, como dije, no sé realmente qué tanta diferencia pueda hacer en la práctica. Y ten en cuenta que en la mayoría de arquitecturas, incluidos procesadores de Intel/AMD, muchas operaciones no se pueden realizar directamente en la memoria, por lo que es forzoso usar registros para valores intermedios. Esto lo menciono porque se pudiera pensar que el incremento/decremento prefijo nos podemos ahorrar alguna instrucción, pero en general, no es así. Aclarado eso, ambas versiones del operador requieren dos cosas: incrementar el valor de la variable y retornar "algo". En el postfijo, el valor original, y en el prefijo el nuevo. La cuestión es si hay interdependencia entre esas dos acciones. Esto es importante porque la mayoría de los procesadores modernos pueden ejecutar más de una instrucción de forma concurrente, siempre que una no dependa de la otra. Teniendo en cuenta que en general necesitamos una copia temporal, con el operador posfijo la asignación y el incremento se pueden hacer simultáneamente, pero en el prefijo el incremente debo ir antes. En realidad esto es casi meramente teórico, ya que en la realidad estos operadores prácticamente nunca son intercambiables, y los casos en los que los son, seguramente el compilador los optimizará de cualquier manera.

No hay nada de malo en preguntar. C++ es un lenguaje muy complejo, y creo que muy pocas cosas en él se podrían considerar "simples". Cosas como la de este tema, no lo son, por supuesto, y encontrar la respuesta tampoco. El estándar es muy complicado, independientemente de cuánta experiencia tengamos. Realmente está dirigido, sobre todo, a creadores de compiladores. No me gusta consultarlo, ya que en realidad no siempre lo entiendo, pero a veces no hay opción, ya que es la única fuente 100% confiable. Por ejemplo, en un vistazo rápido al artículo Order of evaluation de cppreference, no encuentro nada que resuelva el asunto concreto de este hilo. Y por ejemplo, esto:


es, como mínimo incompleto, al menos en C++17, ya que la parte en negrita (que no aparece en la especificación del estándar) implica que es posible que la asignación suceda antes que los efectos colaterales del lado derecho, lo cual no es cierto. Si lo fuera, el resultado de esto:

int n = 5;
numeros[n] = n++;

seguiría indefinido. Sería posible que termináramos modificando numeros[5], ya que, si al momento de la asignación no se ha producido el efecto colateral del operando derecho, por definición, n sigue valiendo 5. Esto no es así. En C++17, siempre modificaremos numeros[6].

En general los compiladores reescriben tu código como les place, la única restricción es que se preserve el "observable behavior"; o sea: el compilador es libre de pasarse tu código por donde le plazca y poner en su lugar otra cosa, sólo está obligado a generar un ejecutable que haga lo mismo. Aprovechando que ya tuve la delicadeza de poder el link al docuemento del Estándar C++17, puedes consultar: parágrafo 4.6 Program execution - Nota 5.

De modo que aunque el compilador no esté obligado, casi seguro que lo hará, eso o algo diferente, a su criterio.

Con los tipos nativos no sólo es más fácil sino que además es muy difícil que notemos la diferencia, normalmente no suele haber un cuello de botella en i++ cuando i es un int. Ahora, si i es de tipo "Clase_con_copy_constructor_vicioso", la diferencia será notable, a no dudarlo.

Ah, ¿por qué la diferencia va a estar en el copy_constructor_vicioso? Por lo dicho, el postincremento devuelve una copia del objeto original sin incrementar.