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

[koala01]

Quoi

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

Code :

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

void laFonction(Lobjet& obj);

sous la forme de

Code :

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

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

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

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"

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

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

[koala01]

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

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

[zais_ethael]

Dans le doute, je viens de vérifier avec Visual C++ 2008 express et le code suivant compile et fonctionne:

Code :

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

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

[koala01]

Rassures moi quand même... Il accepte de compiler et de travailler si tu transforme l'argument en référence constante

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

[Davidbrcz]

Hum.
Un Warning pour ce genre de chose c'est très très faible 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 )

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

[JolyLoic]

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

Code :

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

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 :

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

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.

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

[koala01]

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

Code :

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

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 :

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

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

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


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

[loufoque]

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)