avis operator >>

Version imprimable

15/12/2009, 10h42
tikam75007

avis operator >>
Bonjour tout le monde,

J'aurais besoin d'un avis sur l'utilisation de >>
Je n'ai pas trop l'habitude de m'en servir.
quelqu'un aurait-il la gentillesse de me confirmer que l'instruction:
Code:

1 2 i=(ihi-ili) >>1
va bien diviser i et (ihi-ilo) par deux?

Je trouve ça ne facilite pas la compréhension du code. Il faut que je m'y fasse ou au contraire, on recommanderait, plutôt quelque chose comme:
Code:

1 2 3 4 i=i/2; ihi=ihi/2; ilo=ilo/2;
Merci par avance
15/12/2009, 11h17
Nogane

Bonjours,
Si tu n'as pas besoin d'optimiser ton programme a l'instruction près, utilise plutôt le '/', c'est beaucoup plus clair.
Remarque que ca ne t'empêche pas de l'écrire sur une seul ligne:

Code:

i = (ihi - ili) / 2;

En plus il faut se méfier de l'opérateur >> sur les nombre signé. Il garde le bit de signe, et ce n'est pas toujours ce qu'on veux.
15/12/2009, 11h18
nouknouk
salut,
Code:

1 2 i=(ihi-ili) >>1;
le code ci-dessus est équivalent à
Code:

1 2 i=(ihi-ili) / 2;
Citation:

Je trouve ça ne facilite pas la compréhension du code.

Eh bien saches que tu n'es pas le seul !

Citation:

Si tu n'as pas besoin d'optimiser ton programme a l'instruction près

Non: dans l'immense majorité des cas, ce genre de pseudo optimisation ne sert carrément à rien: le compilateur sait très bien faire l'optimisation tout seul ; donc pas besoin de pondre un code imbuvable pour obtenir le même résultat au niveau des performances.

D'une façon plus générale, 99% des optimisations dans ce genre (ie. qui ne concernent pas l'algorithmique) sont effectuées par le compilateur et (hormis cas très rare), tu peux être à peu près certain que le compilo saura bien mieux optimiser que la plupart des développeurs, même expérimentés.

Donc savoir à quoi correspond ce genre de notation, c'est toujours bon à prendre ; l'utiliser dans son propre code (surtout s'il doit être relu par d'autres) est amha plus contre-productif qu'autre chose (source d'erreurs, d'incompréhensions, de perte de temps de dév., ... pour un gain nul).
15/12/2009, 11h47
tikam75007
Merci pour vos réponses,
j'ai néanmoins encore besoin d'une précision.

si on écrit
Code:

1 2 i=(ihi-ilo)>>1;
i sera divisé par 2
mais est-ce que ihi et ilo seront divisé par 2 individuellement,
ou i se voit seulement attribuer comme valeur la différence ihi-ilo divisé par 2?

C'est important de le savoir car la suite du code fait appel à ihi et ilo.

Merci
15/12/2009, 11h51
3DArchi

Histoire que le message passe bien, on va rajouter une couche :
-> La seule bonne raison d'utiliser le décalage de bit est dans la manipulation des drapeaux où on veut effectivement signifier au lecteur de code que l'on joue avec des drapeaux et qu'on veut accéder à un (ou des) bit(s) en particulier.
-> Sinon, utilises le /2 si tu veux faire une division par 2. Ça génère le même code que le décalage de bit... mais c'est beaucoup plus simple à comprendre !
15/12/2009, 11h53
3DArchi
Citation:
Envoyé par tikam75007

Merci pour vos réponses,
j'ai néanmoins encore besoin d'une précision.

si on écrit

Code:

1 2 i=(ihi-ilo)>>1;

i sera divisé par 2
mais est-ce que ihi et ilo seront divisé par 2 individuellement,
ou i se voit seulement attribuer comme valeur la différence ihi-ilo divisé par 2?

C'est important de le savoir car la suite du code fait appel à ihi et ilo.

Merci
>> s'applique à l'expression qui le précède mais ne la modifie pas. Donc i vaut (ihi-ilo)>>1, mais ihi et ilo ne sont pas changés.
15/12/2009, 11h59
tikam75007

ok 3D archi,

merci pour la précision,
je venais de faire un nouveau poste pour demander le sort réservé à (ihi-ilo).
Merci à tous.
15/12/2009, 11h59
Nogane

Citation:

Non: dans l'immense majorité des cas, ce genre de pseudo optimisation ne sert carrément à rien: le compilateur sait très bien faire l'optimisation tout seul ; donc pas besoin de pondre un code imbuvable pour obtenir le même résultat au niveau des performances.

Citation:

Histoire que le message passe bien, on va rajouter une couche :
-> La seule bonne raison d'utiliser le décalage de bit est dans la manipulation des drapeaux où on veut effectivement signifier au lecteur de code que l'on joue avec des drapeaux et qu'on veut accéder à un (ou des) bit(s) en particulier.
-> Sinon, utilises le /2 si tu veux faire une division par 2. Ça génère le même code que le décalage de bit... mais c'est beaucoup plus simple à comprendre !

Ok ok! j'ai bien comprit maintenan^^
C'est juste que y'a 15 ans on disait exactement le contraire. Il faut que je me mette au gout du jour.
Si ca peux rassurer, je n'aurais utilisé ce genre de bidouille (>>) que dans un code aillant une réel nécessité d'optimisation, c'est a dire assez rarement finalement.
15/12/2009, 12h15
nouknouk

Citation:

Envoyé par Nogane

C'est juste que y'a 15 ans on disait exactement le contraire. Il faut que je me mette au gout du jour.

C'était pertinent il y a 15 ans, mais ça ne l'est plus désormais:

- la puissance n'est plus un problème aussi critique que de nos jours, pour deux raisons:

* un processeur moyen/haut de gamme coûte désormais beaucoup moins cher par exemple qu'un développeur pendant une journée. Il y a 15 ans c'était exactement l'inverse.

* la plupart des ordinateurs, même bas de gamme ont 10x plus de puissance que ce que le commun des mortels n'en utilise (en gros: hors traitement vidéo, grosse compression, 3D et jeux): désormais le plus petit des processeurs sur le marché s'acquite sans souci de l'ensemble des tâches qu'on lui demande ; cf. les netbooks et leurs processeurs Atom.

- les compilateurs ont fait d'immenses progrès en 15 ans. Désormais il sont capables de très bien comprendre la 'logique' d'un code (simple) et de l'adapter pour qu'il soit le plus performant possible.

- les architectures de processeurs se sont énormément complexifiées avec le temps (instruction supplémentaires, gestion du cache, ...); et de plus en plus rares sont les développeurs qui peuvent prétendre avoir les connaissances suffisantes pour prévoir à l'avance ce qui optimisera quelque-chose ou pas.

De fait, l'optimisation de nos jours ne se fait plus vraiment à priori, mais à postériori: on code en suivant - certes - des bonnes règles de conduite de base, mais sans se soucier au final des moindres optimisations pour gagner deux nanosecondes par fonction.
Une fois une première version fonctionnelle, si (et seulement si) on est confronté à des problèmes de performance, on va faire du 'profiling' pour identifier les 'points chauds' du code et n'optimiser que ces parties là.
C'est beaucoup plus productif au final.
15/12/2009, 12h15
3DArchi

Citation:

Envoyé par Nogane

C'est juste que y'a 15 ans on disait exactement le contraire. Il faut que je me mette au gout du jour.

C'est exactement le genre de bidouille que je pouvais faire il y a 15 ans en C pour des plateformes embarquées ... mais qu'aujourd'hui sont devenues non seulement inutiles mais contreproductive dans le sens où elles obscurcissent le code.

Salut

Citation:

Envoyé par 3DArchi

Histoire que le message passe bien, on va rajouter une couche :
-> La seule bonne raison d'utiliser le décalage de bit est dans la manipulation des drapeaux où on veut effectivement signifier au lecteur de code que l'on joue avec des drapeaux et qu'on veut accéder à un (ou des) bit(s) en particulier.

Et encore, j'aurais tendance, pour éviter tout malentendu, à placer ces drapeaux dans une énumération...

J'aurais ainsi
Code:

1 2 3 4 5 6 7 8 enum flag { drapeau0 = 1<<0, //plutot que = 1 drapeau1 = 1<<1, // plutot que =2 drapeau2 = 1<<2, //plutot que = 4 /*...*/ drapeau25 = 1<<25, // plutot que ... heu... ca fait combien ??? :P:D };
De cette manière, l'utilisateur ne doit s'inquiéter que du drapeau qu'il veut activer / désactiver, sans même avoir besoin de s'inquiéter de sa valeur réelle.

Si les différents drapeaux ne sont pas exlusifs, il faudra cependant envisager de créer une surcharge des opérateur &, | et ^ ;)