"const" et performances

Version imprimable

23/06/2008, 12h00
mister3957

"const" et performances

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
23/06/2008, 12h28
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 :D) 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 ;):D)
23/06/2008, 12h34
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
23/06/2008, 12h43
ram-0000

Citation:

Envoyé par mister3957

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

D'accord à 200 %

Citation:

Envoyé par mister3957

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.
23/06/2008, 12h51
mister3957

Ok d'accord, merci beaucoup pour ces précisions.
23/06/2008, 13h00
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" ;):P

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 :D)
  - 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 ;):D)
Pour rappel, même si je n'aime pas particulièrement le code suivant:

Code:

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

est autorisé avec les références constantes uniquement (ou avec les objets ;))
23/06/2008, 13h16
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:

Citation:

Envoyé par koala01

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

Code:

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++).
23/06/2008, 13h28
koala01

Quoi :question:

VC++ accepte d'appeler une fonction dont le prototype est

Code:

void laFonction(Lobjet& obj);

sous la forme de

Code:

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

:question: :question:

Ou, plus vraisemblablement, me suis-je mal exprimé :question:

J'aurais du écrire : "Quand une fonction prend une référence sur un objet, il faut que cette référence soit constante pour pouvoir utiliser un objet anonyme" :aie:

Si tu me confirmes que VC++ accepte l'appel de cette fonction tel que je l'ai donné, je désespère à jamais de ce compilateur :aie:
23/06/2008, 13h30
zais_ethael

Tu t'es bien exprimé et c'est bien ce que j'ai voulu dire, Visual C++ dévie du standard en permettant ce genre de choses (ou alors ça a été corrigé dans les versions récentes, mais j'en doute car alors bonjour la rétro compatibilité :D)
C'est ennuyeux, car il n'y a plus vraiment de situation qui oblige un débutant à utiliser la constance, et donc il ne l'apprend pas.
23/06/2008, 13h36
koala01

C'est donc encore pis que tout ce que je craignais :aie:

Je ne tenais déjà pas la firme de redmond en très grande estime pour une série d'autres choses, mais là, j'ai l'impression que tu viens de torpiller mes dernières illusions :aie:
23/06/2008, 13h40
zais_ethael
Dans le doute, je viens de vérifier avec Visual C++ 2008 express et le code suivant compile et fonctionne:
Code:

1 2 3 4 5 6 7 8 9 10 11 struct machin { int x; int y; }; void bidule(machin & z) { } void main() { bidule(machin()); }
Donc, non, il semblerait qu'ils n'aient toujours pas changé de politique à ce sujet :)
23/06/2008, 13h53
koala01

Rassures moi quand même... Il accepte de compiler et de travailler si tu transforme l'argument en référence constante :question:
23/06/2008, 14h03
Médinoc

Par contre, si vous compilez en /W4, ce code vous donne un warning C4239 (du moins, c'est le cas sous 2005, et c'était apparemment déjà le cas sous 2003)
23/06/2008, 14h53
Davidbrcz

Hum.
Un Warning pour ce genre de chose c'est très très faible :aie: et encore ce warning il n'apparait qu'en level 4 d'après ce que j'ai compris (j'ai très peu utilisé VS). C'est vraiment horrible (re :aie:)
23/06/2008, 15h22
Médinoc

En effet.
Mais quand on programme en C++ standard, on peut essayer de voir ce que ça donne si on désactive les extensions...
23/06/2008, 21h17
JolyLoic
En choisissant de désactiver les extensions du langage (/Za) (1), on obtient bien une erreur de compilation :
Code:

1 2 c:\...\.cpp(10) : error C2664: 'bidule' : impossible de convertir le paramètre 1 de 'machin' en 'machin &' Une référence non const peut uniquement être liée à lvalue
Et à mon avis, ils vont de toute manière devoir changer ça rapidement avec l'intraduction des rvalue reference, sinon, ça risque d'être un beau bordel.

Pour info, il signale même l'autre erreur qu'il y a dans ton code, l'avais-tu mise là volontairement ? :

Code:

c:\...\.cpp(9) : warning C4326: le type de retour de 'main' doit être 'int' au lieu de 'void'

(1) : Par contre, les entêtes standard de windows refusent de compiler quand ce /Za est utilisé, ce qui en limite sérieusement l'usage.
23/06/2008, 21h24
JolyLoic

Citation:

Envoyé par koala01

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.
23/06/2008, 21h37
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.
24/06/2008, 03h58
koala01
Citation:
Envoyé par JolyLoic

En choisissant de désactiver les extensions du langage (/Za) (1), on obtient bien une erreur de compilation :

Code:

1 2 c:\...\.cpp(10) : error C2664: 'bidule' : impossible de convertir le paramètre 1 de 'machin' en 'machin &' Une référence non const peut uniquement être liée à lvalue

Et à mon avis, ils vont de toute manière devoir changer ça rapidement avec l'intraduction des rvalue reference, sinon, ça risque d'être un beau bordel.

Pour info, il signale même l'autre erreur qu'il y a dans ton code, l'avais-tu mise là volontairement ? :

Code:

c:\...\.cpp(9) : warning C4326: le type de retour de 'main' doit être 'int' au lieu de 'void'

Oupppssss.... absolument pas... je voulais mettre l'appel dans une fonction, mais pas dans main, à vrai dire :aie:...

j'ai écrit et relu trop vite...: j'ai pensé void f(), puis int main(), et j'ai fait un "mix" très malheureux des deux :aie:

(1) : Par contre, les entêtes standard de windows refusent de compiler quand ce /Za est utilisé, ce qui en limite sérieusement l'usage.
24/06/2008, 14h02
loufoque

Citation:

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.

Ça n'a rien à voir. C'est en RAM, mais c'est de la mémoire en lecture seule (cette zone doit avoir sa propre page mémoire en lecture seule je suppose)
24/06/2008, 14h20
ram-0000

Citation:

Envoyé par loufoque

Ça n'a rien à voir. C'est en RAM, mais c'est de la mémoire en lecture seule (cette zone doit avoir sa propre page mémoire en lecture seule je suppose)

Non, non, je parlais des logiciels embarqués avec les variables de type "const" qui restent dans le segment de ROM

Fuseau horaire GMT +2. Il est actuellement 14h39.