Discussion :

[mister3957]

Bonjour,


Outre le faite que le mot clé "const" améliore la sécurité des traitements dans un programme, je voudrais savoir également si ça améliorait également la performance ?

Autant sur des paramètres que des fonctions ou des membres ?



Merci,

A bientôt

[koala01]

Salut,

Une chose est sure, c'est que cela ne nuit pas aux performances...

J'aurais - mais sans aucun moyen de la prouver ou de l'expliquer - la sensation que cela pourrait même les améliorer du fait que les objets constants sont placé dans une zone mémoire "read-only"...

Quoi qu'il en soit, plutôt de t'inquiéter des performance d'une écriture donnée par rapport à une autre, l'idéal est toujours de rappeler de préférer l'amélioration de l'algorithme

Dans 97% des cas (et ce n'est pas moi qui le dit ) l'optimisation prématurée est le chemin de toutes les enfers.

Cela signifie que les optimisations d'écritures ne seront nécessaires et utiles que... dans 3 lignes sur 100 (et comme certains se basent généralement sur le fait qu'une fonction ne devrait jamais faire plus de 50 lignes, cela revient à dire que, dans la plupart des fonctions, tu ne trouveras pas une ligne où ce soit nécessaire )

[mister3957]

C'est que je dois reprendre un projet, le nettoyer etc...

Pour moi les const sont très important, c'est une manière supplémentaire de guider un développeur.
Mais pour les imposer, il va me falloir plusieurs arguments et si le gain de performance pouvait m'aider...


Merci pour ta réponse,


A bientôt

[ram-0000]

Pour moi les const sont très important, c'est une manière supplémentaire de guider un développeur

D'accord à 200 %

Mais pour les imposer, il va me falloir plusieurs arguments et si le gain de performance pouvait m'aider...

Tu peux argumenter en indiquant que plus de contrôles effectués par le compilateur permettant d'augmenter la fiabilité du programme.

Par contre, en terme de performances pures, je n'y croie pas. Le segment des données "const" est en RAM comme le segment des données "non const" donc c'est pareil.

Et même dans certains cas (logiciel embarqués) donc avec de la mémoire ROM et RAM, les variables "const" vont être mises et laissées en ROM et parfois le temps d'accès à la ROM est supérieur au temps d'accès à la RAM.

[mister3957]

Ok d'accord, merci beaucoup pour ces précisions.

[koala01]

Je crois que toute personne ayant déjà eu à réfléchir sur le "pourquoi la méthode qui ne devait pas modifier un membre l'a fait" sera d'accord sur la nécessité des "const"

Personnellement, j'axerais mon argumentation sur les points suivants:

• Cela ne nuit pas aux performances, et c'est donc une opération nulle à ce point de vue
• Par contre, cela augmente les performances de l'équipe, améliore la robustesse du code et facilite le débuggage en:
  
  • Permettant de supprimer toute une partie de code si une modification de valeur indue survient (si elle survient, c'est quelque part où cette valeur n'est pas constante... qui l'eut crut )
  • favorisant la mise en évidence de problèmes au moment de la compilation, plutôt que d'attendre l'apparition aléatoire d'un problème... qui se fera toujours au pire moment.
  • permettant (dans le cas d'arguments) de travailler sur des références anonymes en cas de besoin (la norme précise qu'une référence anonyme doit être constante )

Pour rappel, même si je n'aime pas particulièrement le code suivant:

Code :

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

laFonction(Lobjet(parma1,param2,param3));

est autorisé avec les références constantes uniquement (ou avec les objets )

[zais_ethael]

Je me souviens avoir entendu parler d'un bouquin (peut-être de Sutter) où l'auteur citait plusieurs idée d'optimisations qui pourraient être apportées par les compilateurs. Il avait entre autre quelques suggestions sur l'utilisation du const (mais déplorait qu'aucun compilateur ne fonctionne de cette façon).

Sinon, la seule forme d'optimisation que je connais (qui est précisée dans la norme) est qu'une variable constante, globale ou statique, d'un type primitif, et déclarée et définie dans un header peut plus ou moins fonctionner à la manière d'un #define (tout comme les enums).

En dehors de ça, je plussoie tous les arguments hors-optimisation dis précédemment. A par peut-être:

Pour rappel, même si je n'aime pas particulièrement le code suivant:

Code :

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

laFonction(Lobjet(parma1,param2,param3));

est autorisé avec les références constantes uniquement (ou avec les objets )

Ce n'est pas vrai dans Visual C++ (ce qui encourage très probablement beaucoup de développeurs à cultiver une ignorance totale du mécanisme de constance en C++).

[JolyLoic]

J'aurais - mais sans aucun moyen de la prouver ou de l'expliquer - la sensation que cela pourrait même les améliorer du fait que les objets constants sont placé dans une zone mémoire "read-only"...

Attention à ne pas confondre "constante" et "constante connue à la compilation". Seule la seconde catégorie est susceptible d'être placée en ROM, et elle est bien plus restreinte que la première.

Pour la question initiale, il n'est pas impossible que l'utilisation de const améliore les performances, mais je ne suis pas certain qu'avec les compilateurs d'aujourd'hui, on voit une différence sensible.

[ram-0000]

Le temps d'accès à la mémoire ROM est largement plus grand que le temps d'accès à la RAM. Mes souvenirs d'électronique ne sont pas trop rouillés.

Par contre, un autre argument en faveur du mot clé "const" est qu'il est possible (et même probable mais je n'ai pas de preuves) que l'optimiseur fasse un meilleur travail si la variable est const.