Pierre Maurette a écrit :if(len> 3 + 5*(dots == 0)) ...
Maintenant imaginons que ce test soit dans un boucle stratégique.
Avantage, on évite un branchement.
Mouais. Pas sûr. Soit ton compilo est pipô, et il va te coller quand
même le branchement caché dans l'opérateur == utilisé dans un contexte
entier, parce qu'en fait il faut lire cet opérateur comme
(dots==0 ? 1 : 0)
Soit il est performant, et il va « supprimer » aussi bien le branchement
inhérent à l'opérateur ?: que celui de l'opérateur == utilisé comme entier.
Et si tu me dis qu'il est compliqué d'optimiser en général l'opérateur
?: pour éviter les sauts, je suis d'accord avec toi, il y a plus de
chances que le compilateur passe du temps à simplifier le if()...
et au passage, il va probablement représenter l'expression complète de
la même manière que l'on utilise ?: ou 5*(==0), donc au final il n'y a
aucune différence, et il vaut mieux prendre l'écriture la plus lisible
(et oui, je suis conscient qu'ici, c'est Charybde et Scylla.)
Pierre Maurette a écrit :
if(len> 3 + 5*(dots == 0)) ...
Maintenant imaginons que ce test soit dans un boucle stratégique.
Avantage, on évite un branchement.
Mouais. Pas sûr. Soit ton compilo est pipô, et il va te coller quand
même le branchement caché dans l'opérateur == utilisé dans un contexte
entier, parce qu'en fait il faut lire cet opérateur comme
(dots==0 ? 1 : 0)
Soit il est performant, et il va « supprimer » aussi bien le branchement
inhérent à l'opérateur ?: que celui de l'opérateur == utilisé comme entier.
Et si tu me dis qu'il est compliqué d'optimiser en général l'opérateur
?: pour éviter les sauts, je suis d'accord avec toi, il y a plus de
chances que le compilateur passe du temps à simplifier le if()...
et au passage, il va probablement représenter l'expression complète de
la même manière que l'on utilise ?: ou 5*(==0), donc au final il n'y a
aucune différence, et il vaut mieux prendre l'écriture la plus lisible
(et oui, je suis conscient qu'ici, c'est Charybde et Scylla.)
Pierre Maurette a écrit :if(len> 3 + 5*(dots == 0)) ...
Maintenant imaginons que ce test soit dans un boucle stratégique.
Avantage, on évite un branchement.
Mouais. Pas sûr. Soit ton compilo est pipô, et il va te coller quand
même le branchement caché dans l'opérateur == utilisé dans un contexte
entier, parce qu'en fait il faut lire cet opérateur comme
(dots==0 ? 1 : 0)
Soit il est performant, et il va « supprimer » aussi bien le branchement
inhérent à l'opérateur ?: que celui de l'opérateur == utilisé comme entier.
Et si tu me dis qu'il est compliqué d'optimiser en général l'opérateur
?: pour éviter les sauts, je suis d'accord avec toi, il y a plus de
chances que le compilateur passe du temps à simplifier le if()...
et au passage, il va probablement représenter l'expression complète de
la même manière que l'on utilise ?: ou 5*(==0), donc au final il n'y a
aucune différence, et il vaut mieux prendre l'écriture la plus lisible
(et oui, je suis conscient qu'ici, c'est Charybde et Scylla.)
Antoine Leca, le 18/06/2010 a écrit :if( dots == 0 ? len > 8 : len > 3 ) ...
Quand pensez-vous ( performance, maintenabilité, ...) ?
Que c'est plus lisible que
if( len > (dots==0)*5+3 ) ...
Je lis assez bien:
if(len > 3 + 5*(dots == 0)) ...
J'utilise assez couramment ce genre de truc en interprêté et quand je
me fiche de la performance. C'est à dire 99,99...% des cas.
Maintenant imaginons que ce test soit dans un boucle stratégique.
Avantage, on évite un branchement. Faudrait s'occuper du /if/, mais ce
n'est pas ici le problème.
Le compilateur ne va pas générer une multiplication, très coûteuse.
Mais certainement une multiplication par une constante, c'est à dire
une paire d'instructions peu coûteuses. Comme on dit à la pétanque, je
pense que selon le contexte, ça se mesure...
Antoine Leca, le 18/06/2010 a écrit :
if( dots == 0 ? len > 8 : len > 3 ) ...
Quand pensez-vous ( performance, maintenabilité, ...) ?
Que c'est plus lisible que
if( len > (dots==0)*5+3 ) ...
Je lis assez bien:
if(len > 3 + 5*(dots == 0)) ...
J'utilise assez couramment ce genre de truc en interprêté et quand je
me fiche de la performance. C'est à dire 99,99...% des cas.
Maintenant imaginons que ce test soit dans un boucle stratégique.
Avantage, on évite un branchement. Faudrait s'occuper du /if/, mais ce
n'est pas ici le problème.
Le compilateur ne va pas générer une multiplication, très coûteuse.
Mais certainement une multiplication par une constante, c'est à dire
une paire d'instructions peu coûteuses. Comme on dit à la pétanque, je
pense que selon le contexte, ça se mesure...
Antoine Leca, le 18/06/2010 a écrit :if( dots == 0 ? len > 8 : len > 3 ) ...
Quand pensez-vous ( performance, maintenabilité, ...) ?
Que c'est plus lisible que
if( len > (dots==0)*5+3 ) ...
Je lis assez bien:
if(len > 3 + 5*(dots == 0)) ...
J'utilise assez couramment ce genre de truc en interprêté et quand je
me fiche de la performance. C'est à dire 99,99...% des cas.
Maintenant imaginons que ce test soit dans un boucle stratégique.
Avantage, on évite un branchement. Faudrait s'occuper du /if/, mais ce
n'est pas ici le problème.
Le compilateur ne va pas générer une multiplication, très coûteuse.
Mais certainement une multiplication par une constante, c'est à dire
une paire d'instructions peu coûteuses. Comme on dit à la pétanque, je
pense que selon le contexte, ça se mesure...
In article ,
Pierre Maurette wrote:Antoine Leca, le 18/06/2010 a écrit :if( dots == 0 ? len > 8 : len > 3 ) ...
Quand pensez-vous ( performance, maintenabilité, ...) ?
Que c'est plus lisible que
if( len > (dots==0)*5+3 ) ...
Je lis assez bien:
if(len > 3 + 5*(dots == 0)) ...
J'utilise assez couramment ce genre de truc en interprêté et quand je
me fiche de la performance. C'est à dire 99,99...% des cas.
Maintenant imaginons que ce test soit dans un boucle stratégique.
Avantage, on évite un branchement. Faudrait s'occuper du /if/, mais ce
n'est pas ici le problème.
Le compilateur ne va pas générer une multiplication, très coûteuse.
Mais certainement une multiplication par une constante, c'est à dire
une paire d'instructions peu coûteuses. Comme on dit à la pétanque, je
pense que selon le contexte, ça se mesure...
Je te trouve bien categorique dans tes hypotheses de generation de code...
Un peu de sens commun ne ferait pas de mal.
Perso:
- j'ecris le code le plus clair que je peux. Deja comme ca, je vois mieux,
et je peux faire de la macro-optimisation.
- une fois que ca marche, je teste. Si ca rame, je regarde qu'est-ce que
j'ai rate cote algorithmiques et optimisations triviales ("low-hanging fruit",
ou comment gagner 90% de performances avec 10% d'effort).
- si vraiment il y a un "hot spot" qui bouffe toutes les perfs, je ne vais
pas m'amuser a supputer. Je sais expliquer a mon compilo de me montrer
l'assembleur qu'il pond, et je sais aussi comment lui faire faire des
optimisations en plus.
In article <mn.a0f87da6a7056d8f.79899@wanadoo.fr>,
Pierre Maurette <maurettepierre@wanadoo.fr> wrote:
Antoine Leca, le 18/06/2010 a écrit :
if( dots == 0 ? len > 8 : len > 3 ) ...
Quand pensez-vous ( performance, maintenabilité, ...) ?
Que c'est plus lisible que
if( len > (dots==0)*5+3 ) ...
Je lis assez bien:
if(len > 3 + 5*(dots == 0)) ...
J'utilise assez couramment ce genre de truc en interprêté et quand je
me fiche de la performance. C'est à dire 99,99...% des cas.
Maintenant imaginons que ce test soit dans un boucle stratégique.
Avantage, on évite un branchement. Faudrait s'occuper du /if/, mais ce
n'est pas ici le problème.
Le compilateur ne va pas générer une multiplication, très coûteuse.
Mais certainement une multiplication par une constante, c'est à dire
une paire d'instructions peu coûteuses. Comme on dit à la pétanque, je
pense que selon le contexte, ça se mesure...
Je te trouve bien categorique dans tes hypotheses de generation de code...
Un peu de sens commun ne ferait pas de mal.
Perso:
- j'ecris le code le plus clair que je peux. Deja comme ca, je vois mieux,
et je peux faire de la macro-optimisation.
- une fois que ca marche, je teste. Si ca rame, je regarde qu'est-ce que
j'ai rate cote algorithmiques et optimisations triviales ("low-hanging fruit",
ou comment gagner 90% de performances avec 10% d'effort).
- si vraiment il y a un "hot spot" qui bouffe toutes les perfs, je ne vais
pas m'amuser a supputer. Je sais expliquer a mon compilo de me montrer
l'assembleur qu'il pond, et je sais aussi comment lui faire faire des
optimisations en plus.
In article ,
Pierre Maurette wrote:Antoine Leca, le 18/06/2010 a écrit :if( dots == 0 ? len > 8 : len > 3 ) ...
Quand pensez-vous ( performance, maintenabilité, ...) ?
Que c'est plus lisible que
if( len > (dots==0)*5+3 ) ...
Je lis assez bien:
if(len > 3 + 5*(dots == 0)) ...
J'utilise assez couramment ce genre de truc en interprêté et quand je
me fiche de la performance. C'est à dire 99,99...% des cas.
Maintenant imaginons que ce test soit dans un boucle stratégique.
Avantage, on évite un branchement. Faudrait s'occuper du /if/, mais ce
n'est pas ici le problème.
Le compilateur ne va pas générer une multiplication, très coûteuse.
Mais certainement une multiplication par une constante, c'est à dire
une paire d'instructions peu coûteuses. Comme on dit à la pétanque, je
pense que selon le contexte, ça se mesure...
Je te trouve bien categorique dans tes hypotheses de generation de code...
Un peu de sens commun ne ferait pas de mal.
Perso:
- j'ecris le code le plus clair que je peux. Deja comme ca, je vois mieux,
et je peux faire de la macro-optimisation.
- une fois que ca marche, je teste. Si ca rame, je regarde qu'est-ce que
j'ai rate cote algorithmiques et optimisations triviales ("low-hanging fruit",
ou comment gagner 90% de performances avec 10% d'effort).
- si vraiment il y a un "hot spot" qui bouffe toutes les perfs, je ne vais
pas m'amuser a supputer. Je sais expliquer a mon compilo de me montrer
l'assembleur qu'il pond, et je sais aussi comment lui faire faire des
optimisations en plus.
Le 21-06-2010, ? propos de
Re: trigraphe dans test conditionnel !,
Marc Espie ?crivait dans fr.comp.lang.c :In article ,
Pierre Maurette wrote:Antoine Leca, le 18/06/2010 a écrit :if( dots == 0 ? len > 8 : len > 3 ) ...
Quand pensez-vous ( performance, maintenabilité, ...) ?
Que c'est plus lisible que
if( len > (dots==0)*5+3 ) ...
Je lis assez bien:
if(len > 3 + 5*(dots == 0)) ...
Ce ne serait pas un peu casse gueule ? Est-on sûrs sur (dots == 0)
renvoie toujours 0 ou 1 et non une valeur non nulle ?
J'ai un vieux compilo qui utilise -1 comme valeur 'vraie' et teste
par rapport à 0 pour savoir si un entier correspond à 'vrai' ou
'faux' (c'est un compilo pré-ansi et je ne me suis jamais penché
depuis sur ce problème, je ne sais pas si ça été mis dans les specs
et mon expérience me dit de se méfier de tels trucs).
Le 21-06-2010, ? propos de
Re: trigraphe dans test conditionnel !,
Marc Espie ?crivait dans fr.comp.lang.c :
In article <mn.a0f87da6a7056d8f.79899@wanadoo.fr>,
Pierre Maurette <maurettepierre@wanadoo.fr> wrote:
Antoine Leca, le 18/06/2010 a écrit :
if( dots == 0 ? len > 8 : len > 3 ) ...
Quand pensez-vous ( performance, maintenabilité, ...) ?
Que c'est plus lisible que
if( len > (dots==0)*5+3 ) ...
Je lis assez bien:
if(len > 3 + 5*(dots == 0)) ...
Ce ne serait pas un peu casse gueule ? Est-on sûrs sur (dots == 0)
renvoie toujours 0 ou 1 et non une valeur non nulle ?
J'ai un vieux compilo qui utilise -1 comme valeur 'vraie' et teste
par rapport à 0 pour savoir si un entier correspond à 'vrai' ou
'faux' (c'est un compilo pré-ansi et je ne me suis jamais penché
depuis sur ce problème, je ne sais pas si ça été mis dans les specs
et mon expérience me dit de se méfier de tels trucs).
Le 21-06-2010, ? propos de
Re: trigraphe dans test conditionnel !,
Marc Espie ?crivait dans fr.comp.lang.c :In article ,
Pierre Maurette wrote:Antoine Leca, le 18/06/2010 a écrit :if( dots == 0 ? len > 8 : len > 3 ) ...
Quand pensez-vous ( performance, maintenabilité, ...) ?
Que c'est plus lisible que
if( len > (dots==0)*5+3 ) ...
Je lis assez bien:
if(len > 3 + 5*(dots == 0)) ...
Ce ne serait pas un peu casse gueule ? Est-on sûrs sur (dots == 0)
renvoie toujours 0 ou 1 et non une valeur non nulle ?
J'ai un vieux compilo qui utilise -1 comme valeur 'vraie' et teste
par rapport à 0 pour savoir si un entier correspond à 'vrai' ou
'faux' (c'est un compilo pré-ansi et je ne me suis jamais penché
depuis sur ce problème, je ne sais pas si ça été mis dans les specs
et mon expérience me dit de se méfier de tels trucs).
JKB, le 21/06/2010 a écrit :Le 21-06-2010, ? propos de
Re: trigraphe dans test conditionnel !,
Marc Espie ?crivait dans fr.comp.lang.c :In article ,
Pierre Maurette wrote:Antoine Leca, le 18/06/2010 a écrit :if( dots == 0 ? len > 8 : len > 3 ) ...
Quand pensez-vous ( performance, maintenabilité, ...) ?
Que c'est plus lisible que
if( len > (dots==0)*5+3 ) ...
Je lis assez bien:
if(len > 3 + 5*(dots == 0)) ...
Ce ne serait pas un peu casse gueule ? Est-on sûrs sur (dots == 0)
renvoie toujours 0 ou 1 et non une valeur non nulle ?
Oui, dots == 0, ou !dots, renvoient 0 ou 1. C'est dans la norme. Même
si dots peut avoir d'autres valeurs.
JKB, le 21/06/2010 a écrit :
Le 21-06-2010, ? propos de
Re: trigraphe dans test conditionnel !,
Marc Espie ?crivait dans fr.comp.lang.c :
In article <mn.a0f87da6a7056d8f.79899@wanadoo.fr>,
Pierre Maurette <maurettepierre@wanadoo.fr> wrote:
Antoine Leca, le 18/06/2010 a écrit :
if( dots == 0 ? len > 8 : len > 3 ) ...
Quand pensez-vous ( performance, maintenabilité, ...) ?
Que c'est plus lisible que
if( len > (dots==0)*5+3 ) ...
Je lis assez bien:
if(len > 3 + 5*(dots == 0)) ...
Ce ne serait pas un peu casse gueule ? Est-on sûrs sur (dots == 0)
renvoie toujours 0 ou 1 et non une valeur non nulle ?
Oui, dots == 0, ou !dots, renvoient 0 ou 1. C'est dans la norme. Même
si dots peut avoir d'autres valeurs.
JKB, le 21/06/2010 a écrit :Le 21-06-2010, ? propos de
Re: trigraphe dans test conditionnel !,
Marc Espie ?crivait dans fr.comp.lang.c :In article ,
Pierre Maurette wrote:Antoine Leca, le 18/06/2010 a écrit :if( dots == 0 ? len > 8 : len > 3 ) ...
Quand pensez-vous ( performance, maintenabilité, ...) ?
Que c'est plus lisible que
if( len > (dots==0)*5+3 ) ...
Je lis assez bien:
if(len > 3 + 5*(dots == 0)) ...
Ce ne serait pas un peu casse gueule ? Est-on sûrs sur (dots == 0)
renvoie toujours 0 ou 1 et non une valeur non nulle ?
Oui, dots == 0, ou !dots, renvoient 0 ou 1. C'est dans la norme. Même
si dots peut avoir d'autres valeurs.
Pierre Maurette a écrit :if(len > 3 + 5*(dots == 0)) ...
Maintenant imaginons que ce test soit dans un boucle stratégique.
Avantage, on évite un branchement.
Mouais. Pas sûr. Soit ton compilo est pipô, et il va te coller quand
même le branchement caché dans l'opérateur == utilisé dans un contexte
entier, parce qu'en fait il faut lire cet opérateur comme
(dots==0 ? 1 : 0)
Soit il est performant, et il va « supprimer » aussi bien le branchement
inhérent à l'opérateur ?: que celui de l'opérateur == utilisé comme entier.
Et si tu me dis qu'il est compliqué d'optimiser en général l'opérateur
?: pour éviter les sauts, je suis d'accord avec toi, il y a plus de
chances que le compilateur passe du temps à simplifier le if()...
et au passage, il va probablement représenter l'expression complète de
la même manière que l'on utilise ?: ou 5*(==0), donc au final il n'y a
aucune différence, et il vaut mieux prendre l'écriture la plus lisible
(et oui, je suis conscient qu'ici, c'est Charybde et Scylla.)
Pierre Maurette a écrit :
if(len > 3 + 5*(dots == 0)) ...
Maintenant imaginons que ce test soit dans un boucle stratégique.
Avantage, on évite un branchement.
Mouais. Pas sûr. Soit ton compilo est pipô, et il va te coller quand
même le branchement caché dans l'opérateur == utilisé dans un contexte
entier, parce qu'en fait il faut lire cet opérateur comme
(dots==0 ? 1 : 0)
Soit il est performant, et il va « supprimer » aussi bien le branchement
inhérent à l'opérateur ?: que celui de l'opérateur == utilisé comme entier.
Et si tu me dis qu'il est compliqué d'optimiser en général l'opérateur
?: pour éviter les sauts, je suis d'accord avec toi, il y a plus de
chances que le compilateur passe du temps à simplifier le if()...
et au passage, il va probablement représenter l'expression complète de
la même manière que l'on utilise ?: ou 5*(==0), donc au final il n'y a
aucune différence, et il vaut mieux prendre l'écriture la plus lisible
(et oui, je suis conscient qu'ici, c'est Charybde et Scylla.)
Pierre Maurette a écrit :if(len > 3 + 5*(dots == 0)) ...
Maintenant imaginons que ce test soit dans un boucle stratégique.
Avantage, on évite un branchement.
Mouais. Pas sûr. Soit ton compilo est pipô, et il va te coller quand
même le branchement caché dans l'opérateur == utilisé dans un contexte
entier, parce qu'en fait il faut lire cet opérateur comme
(dots==0 ? 1 : 0)
Soit il est performant, et il va « supprimer » aussi bien le branchement
inhérent à l'opérateur ?: que celui de l'opérateur == utilisé comme entier.
Et si tu me dis qu'il est compliqué d'optimiser en général l'opérateur
?: pour éviter les sauts, je suis d'accord avec toi, il y a plus de
chances que le compilateur passe du temps à simplifier le if()...
et au passage, il va probablement représenter l'expression complète de
la même manière que l'on utilise ?: ou 5*(==0), donc au final il n'y a
aucune différence, et il vaut mieux prendre l'écriture la plus lisible
(et oui, je suis conscient qu'ici, c'est Charybde et Scylla.)
Oui, dots == 0, ou !dots, renvoient 0 ou 1. C'est dans la norme. Même si dots
peut avoir d'autres valeurs.
Oui, dots == 0, ou !dots, renvoient 0 ou 1. C'est dans la norme. Même si dots
peut avoir d'autres valeurs.
Oui, dots == 0, ou !dots, renvoient 0 ou 1. C'est dans la norme. Même si dots
peut avoir d'autres valeurs.
Marc Boyer a écrit :Voilà. A titre personnel, je trouve la version originale
plutôt pas mal. Mais peut-être que l'opérateur ?: va dérouter
des programmeurs moins habitués.
Ah oui, pourquoi ?
Disons qu'il serait surprenant qu'un bon programmeur C soit surpris par
ce code ;-)
Quant aux autres, il vaudrait mieux qu'ils codent dans un autres
langage, peut-être...
Marc Boyer a écrit :
Voilà. A titre personnel, je trouve la version originale
plutôt pas mal. Mais peut-être que l'opérateur ?: va dérouter
des programmeurs moins habitués.
Ah oui, pourquoi ?
Disons qu'il serait surprenant qu'un bon programmeur C soit surpris par
ce code ;-)
Quant aux autres, il vaudrait mieux qu'ils codent dans un autres
langage, peut-être...
Marc Boyer a écrit :Voilà. A titre personnel, je trouve la version originale
plutôt pas mal. Mais peut-être que l'opérateur ?: va dérouter
des programmeurs moins habitués.
Ah oui, pourquoi ?
Disons qu'il serait surprenant qu'un bon programmeur C soit surpris par
ce code ;-)
Quant aux autres, il vaudrait mieux qu'ils codent dans un autres
langage, peut-être...
Mais j'avais plutôt tendance à dire à mes étudiants que leur code
devait pouvoir être relu par quelqu'un de moins intelligent. C'est de
l'humour, mais ça marquait.
Mais j'avais plutôt tendance à dire à mes étudiants que leur code
devait pouvoir être relu par quelqu'un de moins intelligent. C'est de
l'humour, mais ça marquait.
Mais j'avais plutôt tendance à dire à mes étudiants que leur code
devait pouvoir être relu par quelqu'un de moins intelligent. C'est de
l'humour, mais ça marquait.