¿Ventaja del operador ternario sobre si otra cosa?

¿Hay alguna ventaja en cuanto al rendimiento o la memoria de usar el operador ternario en lugar de hacerlo (o al revés)? Por ejemplo, un caso a continuación:

int x=0, y=1, z=2, a=0; a= x ? y : z; 

alternativa:

 if ( x != 0 ){ a = y; }else{ a = z; } 

Si observa el desassembly de ambos enfoques, generalmente son los mismos en cualquier comstackdor moderno que conozco. El operador ternario es solo una forma compacta de escribir lo mismo.

Aquí hay un ejemplo usando gcc 4.2.1 en Mac OS X:

Con si / else:

 int x = 1; int y = 2; int z; if (x < y) { z = 3; } else { z = 4; } 

Con el operador ternario:

 int x = 1; int y = 2; int z = (x < y) ? 3 : 4; 

Si ejecuta gcc -S test.c en ambos, obtendrá este ensamblaje para la versión if / else:

  movl $1, -16(%rbp) movl $2, -20(%rbp) movl -16(%rbp), %eax movl -20(%rbp), %ecx cmpl %ecx, %eax jge LBB1_2 movl $3, -12(%rbp) jmp LBB1_3 LBB1_2: movl $4, -12(%rbp) 

Y esto para la versión del operador ternario:

  movl $1, -12(%rbp) movl $2, -16(%rbp) movl -12(%rbp), %eax movl -16(%rbp), %ecx cmpl %ecx, %eax jge LBB1_2 movl $3, -20(%rbp) jmp LBB1_3 LBB1_2: movl $4, -20(%rbp) 

Las compensaciones de registro son diferentes, pero funcionalmente, el código hace lo mismo. Agrega dos literales a dos registros diferentes, luego compara y salta basado en el resultado de la comparación.

Los comstackdores son generalmente lo suficientemente inteligentes como para optimizar ambos en las mismas instrucciones. Es mejor utilizar el operador ternario sin asumir la optimización del comstackdor.

En cualquier comstackdor moderno generalmente no hay diferencia entre esos dos.

Por lo tanto, es solo una cuestión de legibilidad y mantenimiento de su código.

La única “ventaja” es que puede usar el operador ternario en una expresión (por ejemplo, argumentos de función), haciendo el código de terser. usando un if , duplicarías la expresión completa.

Use lo que sea más legible en sus circunstancias particulares.

Preocúpese de la eficiencia solo cuando haya medido que tiene un problema de rendimiento.

Con toda probabilidad, el comstackdor generará el mismo código.