Discussion :

[darkhades]

Dans un soucis de recherche d'optimisation, je me pose la question qu'est-ce qui serait le plus optimise au niveau du temps (et non pas des ressources), une ternaire ou une suite d'if/else if/else?
Apres avoir fait des recherches je n'ai rien trouve c'est pour ca que je viens poser la question ici.

Merci
Cordialement

[Neckara]

C'est juste une écriture différente.
Je ne pense pas que le compilateur fasse une différence entre l'opérateur ternaire et le if/else.

[Bktero]

Une personne avait fait un test comparatif des codes ASM générés pour une structure if / else et une structure ternaire. Tu pourras retrouver ses commentaires ici : http://www.developpez.net/forums/d12...e/#post6722871
Avec le compilateur et la cible utilisés, il n'avait pas de différence. Tu peux essayer de regarder avec ton compilateur ce que ça donne.

De plus, je pense qu'il y a beaucoup d'optimisations à faire avant de remplacer des if / else par des structures ternaires. Si tu as encore d'autres choses à optimiser, ça me parait plus intéressant à faire que de s'attaquer à bencher les structures ternaires.

[gangsoleil]

Bonjour,

Dans un soucis de recherche d'optimisation

Regarde les profileurs de code, type gprof ou purify/quantify, qui t'indiqueront dans quelles fonctions tu passes le plus de temps.
Ensuite seulement, commence a optimiser ces fonctions.

[darkhades]

Merci pour ces reponses, pour l'optimisation j'utilise gprof, donc pas de soucis pour cela, mais si je peux remplacer certain if un peu sal par une ternaire propre j'aime bien

[gangsoleil]

si je peux remplacer certain if un peu sal par une ternaire propre j'aime bien

En general, on considere plutot le contraire : l'utilisation d'ecritures explicites est plus propre que l'utilisation de notations un peu absconses

[ram-0000]

En general, on considere plutot le contraire : l'utilisation d'ecritures explicites est plus propre que l'utilisation de notations un peu absconses

et permet à l'optimiseur du compilateur de code de mieux travailler.

[diogene]

Personnellement, je ne trouve pas que l'opérateur ternaire soit particulièrement obscur. Naturellement, il ne faut pas s'amuser en les emboîter, parce que, là, ça devient vite illisible (mais les if/else aussi). C'est un méconnu, car le programmeur trouve toujours des alternatives à son utilisation et n'est pas motivé pour se familiariser avec.

Son intérêt est plus abstrait pour le programmeur : il constitue une expression alors que if/else ne l'est pas. Il peut être utilisé partout où on attend une expression. C'est donc un outil supplémentaire à la disposition du programmeur pour simplifier le code !

Un exemple (évidemment un peu exotique),

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
//(1)
if (a ? b : c) ...
//est presque équivalent à
//(2)
if(a&& b || !a&&c)...

(2) est-il beaucoup plus lisible que (1) ? Il peut amener deux fois l'évaluation de a. Et si cette évaluation a des effets de bords, il faut alors passer par une variable intermédiaire.
Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
//(2')
x = a;
if(x&& b || !x&&c)...

Croyez vous vraiment que la deuxième forme soit plus claire (et plus efficace) que la première ? Il ne faut donc pas généraliser.

[Obsidian]

Personnellement, je ne trouve pas que l'opérateur ternaire soit particulièrement obscur.

+1 !

Naturellement, il ne faut pas s'amuser en les emboîter, parce que, là, ça devient vite illisible (mais les if/else aussi).

Et encore, si l'on imbrique des opérateurs ternaires de façon terminale, par exemple de cette façon :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
    s = i==1 ? "Un"
      : i==2 ? "Deux"
      : i==3 ? "Trois"
      : i==4 ? "Quatre"
      : i==5 ? "Cinq"
      :        "Indéterminé" ;

Ce n'est pas non plus franchement abscons. Ça aurait même plutôt tendance à éclaircir le code au maximum en ne faisant apparaître pratiquement que les données.

[gangsoleil]

Et encore, si l'on imbrique des opérateurs ternaires de façon terminale, par exemple de cette façon :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
    s = i==1 ? "Un"
      : i==2 ? "Deux"
      : i==3 ? "Trois"
      : i==4 ? "Quatre"
      : i==5 ? "Cinq"
      :        "Indéterminé" ;

Ce n'est pas non plus franchement abscons. Ça aurait même plutôt tendance à éclaircir le code au maximum en ne faisant apparaître pratiquement que les données.

Pour moi, ce genre de code est typiquement un code difficilement lisible. En tout cas, plus qu'un switch.

Sur un exemple, notamment avec a, b et c, l'utilisation de l'operateur ternaire est toujours lisible. Le probleme, c'est que dans un vrai code, on rencontre rarement des exemples aussi simples.

L'exemple un peu moins simple suivant me semble completement illisible avec un operateur ternaire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
(config == NULL) ? print_error ("null pointer not allowed") 
    : config.filename == NULL ? print_error ("cannot open NULL file") 
    : file = fopen (config->filename, "r") ;

Dans un hello_world, utiliser l'operateur ternaire ou n'importe quoi d'autre importe peu. Dans un code qui doit etre maintenable et lisible rapidement par n'importe qui, je trouve souvent qu'il n'a pas d'interet.

[Neckara]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
      (config == NULL)          ?   print_error ("null pointer not allowed") 
 
    : config.filename == NULL   ?   print_error ("cannot open NULL file") 
 
    : file = fopen (config->filename, "r") ;

C'est déjà un peu plus lisible^^

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
if(config == NULL)
       print_error ("null pointer not allowed");
else if(config.filename == NULL)
        print_error ("cannot open NULL file");
else
         file = fopen (config->filename, "r") ;

Après je pense que c'est aussi une question d'habitude.
Il vaudrait alors mieux utiliser if/else if/else plutôt que l'opérateur ternaire car les lecteurs ont plus l'habitude des if/else if/else.

En effet, pour la première version, il faut que je passe quelques seconde à me rappeler que ce qui est entre le ':' et le '?' correspond à la condition du else if etc ... alors qu'avec les if, c'est plus automatique.

[ternel]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
    s = i==1 ? "Un"
      : i==2 ? "Deux"
      : i==3 ? "Trois"
      : i==4 ? "Quatre"
      : i==5 ? "Cinq"
      :        "Indéterminé" ;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
(config == NULL) ? print_error ("null pointer not allowed") 
    : config.filename == NULL ? print_error ("cannot open NULL file") 
    : file = fopen (config->filename, "r") ;

Il y a une énorme différence entre ces deux codes

Le premier est une utilisation comme expression, le second comme une instruction (expression non affectée).

Dans le premier cas, il s'agit de condenser un code pas forcément lisible non plus:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
switch(i){
      case 1 : s = "Un"; break;
      case 2 : s = "Deux"; break;
      case 3 : s = "Trois"; break;
      case 4 : s = "Quatre"; break;
      case 5 : s = "Cinq"; break;
      default : s = "Indéterminé"; break;
}

Moi, je préfère effectivement un ternaire bien indenté

Bonus, la version ternaire garantie l'affectation, alors qu'il est toujours possible d'oublier le default (entre autre dans un vrai code).
Autre bonus, cela permet aussi une utilisation comme initialiseur:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

const char* chaine = condition?"succes":"echec"

[diogene]

Personnellement, je le formaterais ainsi , (attention aux parenthèses supplémentaires à ajouter):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
(config == NULL) ? print_error ("null pointer not allowed") 
                 : (config.filename == NULL) ? print_error ("cannot open NULL file") 
                                             : (file = fopen (config->filename, "r")) ;

Maintenant, je n'utiliserais pas l'opérateur ternaire sur ce genre de code :

1- la logique de l'opérateur ternaire est
expression booléenne ? expression1 : expression2
et ici la logique du code est plutôt
expression booléenne ? instruction1 : instruction2
ce qui correspond bien à la fonctionnalité du if/else

2- Il y a des contraintes, injustifiées ici, à l'emploi de l'opérateur ternaire : les deux expressions, expressions1 et expressions2, doivent être de type compatible, ce qui n'est (sans doute) pas le cas ici. De plus, si print_error() renvoie void ...
L'utilisation du ternaire demanderai une écriture

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
file = (config == NULL) ? print_error ("null pointer not allowed") 
                        : (config.filename == NULL) ? print_error ("cannot open NULL file") 
                                                    : fopen (config->filename, "r") ;

Avec print_error() renvoyant un (FILE*) NULL

Bref, si je ne répugne pas à utiliser l'opérateur ternaire, je ne le considère pas comme la panacée.

@Neckara

En effet, pour la première version, il faut que je passe quelques seconde à me rappeler que ce qui est entre le ':' et le '?' correspond à la condition du else if etc ... alors qu'avec les if, c'est plus automatique.

C'est ce que je disais plus haut :

C'est un méconnu, car le programmeur trouve toujours des alternatives à son utilisation et n'est pas motivé pour se familiariser avec.

[moins1]

Ça reste pratique l'opérateur ternaire ?:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

printf("%d maison%s", n, n > 1 ? "s": "");

Un peu naïf comme exemple mais j'avais le cerveau à off