¿No es un error la optimización del valor de retorno (RVO)?

Question

Tal vez estoy haciendo una pregunta tonta, pero miré la página de la wikipedia para RVO here y no pude dejar de preguntarme si ese comportamiento es incorrecto. Lo probé en mi máquina y RVO se pateó completamente a pesar del nivel de optimización. ¿Y si hubiera realmente algo BIG ocurriendo en un constructor? Sé que no debería, pero ¿y si? No puedo entender por qué RVO aún ocurrirá cuando haya efectos secundarios en el constructor.

EDITAR: -fno-elide-constructors parece detener a RVO. Pero la pregunta permanece.

EDIT2: En una nota más seria, ¿cuánta gente sabe algo como esto? Tal vez en el estándar, pero sigue siendo una característica realmente fea como yo lo veo. Al menos los compiladores deberían deshabilitarlo de manera predeterminada y proporcionar un cambio para las personas que lo saben. :)

EDIT 3: Sigo insistiendo en que esto es realmente malo. :). No creo conocer ninguna otra restricción de idioma como esta que vaya directamente en contra de la sintaxis del lenguaje. Todo lo demás arroja errores de compilador o enlazador, ¿verdad?

Answer 1

Los mandatos estándar que las operaciones con la preocupación de estado observable no debe ser optimizado de distancia, a excepción de la construcción copia en ciertas circunstancias un programa. No debe confiar en los constructores de copia para que se ejecuten, incluso si tienen efectos secundarios que espera ver (por ejemplo, salida de la consola).

Answer 2

Definir "incorrecto". El lenguaje C++ permite explícitamente este tipo de optimización aunque sea observable. Si el comportamiento de su programa depende de una implementación específica, desafortunadamente no está usando ISO C++, sino algún dialecto.

Answer 3

Como se dijo en las otras respuestas, el compilador puede optimizar incluso los constructores de copia no triviales y los operadores de asignación.

12.8.15

Cuando se cumplen ciertos criterios, se permite una implementación de omitir la construcción copia de un objeto de clase, incluso si el constructor de copia y/o destructor del objeto tiene efectos secundarios. En tales casos, la implementación trata el origen y el destino de la operación de copia omitida como simplemente dos formas diferentes de referirse al mismo objeto, y la destrucción de ese objeto se produce en el momento posterior en que los dos objetos habrían sido destruido sin la optimización . Esta elisión de operaciones de copia está permitida en las siguientes circunstancias (que pueden combinarse para eliminar copias múltiples):

- en una declaración de devolución en una función con un tipo de devolución de clase, cuando la expresión es el nombre de medicamentos basados ​​en automática de objetos con el mismo tipo cv-calificada como el tipo de retorno de la función, la operación de copia se puede omitir construyendo el automático de objetos directamente en el valor devuelto por la función

- cuando un objeto clase temporal que no ha sido obligado a una referencia (12.2) que se va a copiar a un objeto de clase con el mismo tipo de cv sin reservas, la operación de copia se puede omitir mediante la construcción del objeto temporal directamente en el blanco de la copia omitido