Discussion :

[tikam75007]

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 :

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

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 :

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

1
2
3
4
 
i=i/2;
ihi=ihi/2;
ilo=ilo/2;

Merci par avance

[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 :

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

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.

[nouknouk]

salut,

Code :

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

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

le code ci-dessus est équivalent à

Code :

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

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

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

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

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).

[tikam75007]

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

si on écrit

Code :

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

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

[3DArchi]

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

si on écrit

Code :

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

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.

[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.

[Nogane]

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.

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.

[nouknouk]

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.

[3DArchi]

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.

[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 !

[koala01]

Salut

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 :

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

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 ^