Version imprimable
Voila, il est plus de minuit et demi maintenant et je me pose une question existencielle :
Les méthodes d'interface et autres méthodes virtuelles "ont-elles le droit" d'être déclarées const?
A moins de cas particuliers, mais je n'en vois pas, même en cherchant, c'est à l'implémentation de décider si, oui ou non, la méthode redéfinie va être amenée à modifier l'objet.
Quel est votre avis la-dessus ?
Oui, elles en ont le droit. Être const fait partie du contrat, et c'est la classe de base qui fixe le contrat. C'est elle qui dit qu'une fonction aura N paramètres de tels ou tels types, c'est aussi elle qui dit si on pourra l'appeler sur un objet constant.
Exemple "bête" :
La méthode Draw ne modifiant pas l'instance, on peut la "const-qualifier", et ainsi elle pourra être appelée sur des objets constants, tout en préservant le polymorphisme désiré.Code:
2
3
4
5
6
7
8
9
10
11
Bonjour,
si j'écris ton exemple tel quel, Alp, j'ai l'erreur "cannot instanciate abstract class" car la méthode Draw de Ball n'est justement pas const alors que celle GraphicObject est déclarée comme l'étant.
Et c'est bien là le fond du problème. Je suis tout à fait d'accord avec vous pour dire que décider de rendre une méthode virtuelle const établi un contrat qui doit suivre une logique et que cela doit être fait lors du design de la classe abstraite de base.
Seulement je trouve pleins de cas où cela pose problème.
Si je reprends l'exemple de l'objet graphique et sa méthode Draw() : l'objet est dans un certain état (position, couleur etc.) et on lui demande de s'afficher en l'état, à priori sans le modifier, de façon à ce que si l'on appelle à nouveau cette méthode juste derrière, le même affichage devrait nous être donné. Donc notre méthode est const vis à vis de l'objet graphique.
Alp, tu as surement raisonné ainsi et j'aurais certainement fait pareil. Mais toujours en continuant l'exemple, imaginons que j'implémente ObjetGraphique et mon implémentation nécessite beaucoups de précalculs non négligeables avant de pouvoir effectivement se dessiner. Ces calculs dépendent de l'état de l'objet et ne devraient pas avoir à être ré-éxécutés si l'état n'a pas changé depuis le dernier appel à Draw(). Et bien, à part en déclarant des variables mutable, je ne peux pas sauver mes précalculs dans Draw().
Voilà ce qui me chiffone depuis hier.
En fait j'ai simplement oublié le const...
Car j'étais fatigué :aie:
Mais tu peux pas casser la qualification const, effectivement. J'édite le code ci-dessus ;)
Et justement, tu peux les déclarer mutable, et alors, ça marche. Je ne vois pas trop ce qui te gène dans ce cas.Citation:
Envoyé par NiamorH
Et le mutable n'est pas là "pour faire plaisir" à la classe de base : Il est là parce que, indépendamment de toute autre chose, ton objet n'est pas sémantiquement modifié par son affichage, le fait qu'il y ait des pré-calculs mis en cache n'étant qu'un détail d'implémentation ne devant pas apparaître dans l'interface.
Pour moi, un truc qui "aide" à comprendre les variables mutables, c'est de se dire que ce ne sont pas des variables à part entière de la classe, juste des détails d'implémentation.
Ce qui est le cas pour la plupart des utilisations de variables mutables: Comptage de références intrusif, cache, et compteurs d'appels...
Salut,
Le role d'une méthode const est de préciser au compilateur "cette méthode ne modifie pas l'objet".
Par le fait de modifier l'objet, il faut comprendre le fait de modifier les "propriétés intrinsèques" qui font que ta balle rouge et bleue d'un diametre de N n'est pas une balle verte et jaune d'un diamètre de 2N, et que, au moment de l'appel, sa position et son "orientation" (le fait que le rouge soit en haut à gauche et le bleu en bas à droite) se seront pas modifiée.
Par contre, si pour t'éviter d'avoir à recalculer en permanence l'aspect à donner à ta balle, tu décide de mettre cet aspect dans un cache, tu te trouve exactement dans le cas d'utilisation d'une variable mutable: ca ne modifie absolument pas les propriétés intrinsèques de la balle, cela ne modifie que la manière dont la méthode d'affichage va représenter la balle dans la situation donnée.
Effectivement, le mot clef mutable est la solution que j'utilise. Mais ça m'a toujours géné d'y avoir recours. Dans ma tête je me suis toujours dis "tu as dû mal penser quelque chose pour en arriver à devoir t'en servir."
Peut être que je me fais du mauvais sang pour rien après tout.
Je me disais la même chose au début, c'est d'ailleurs pourquoi j'ai restreint mon utilisation de mutable au comptage de références intrusif et aux caches...
Effectivement, tu te fais beaucoup de mauvais sang pour rien...
Bien sur, comme beaucoup de choses en programmation, il faut toujours se poser la question de savoir si oui ou non il est opportun de déclarer un membre mutable...
Bien sur, l'abus de déclaration de membres mutables est au minimum le signe d'une réflexion sans doute erronée.
Mais, une fois que tu a clairement défini qu'un membre agit comme un cache, comme une machine à état qui peut devenir invalide à n'importe quel moment (y compris au sein de méthodes constantes), et que la modification de ce membre ne modifie en rien les "propriétés intrinsèques" de l'objet en cours, tu es clairement dans le cadre dans lequel il est "opportun" de déclarer le membre mutable ;)
Oui mais c'est aussi parce qu'on est parti d'un exemple qui s'y prétait déjà bien : la balle se dessine et met à jour un cache de précalculs pour la fois suivante. Le cache n'a d'utilité que pour cette méthode Draw(), au pire une ou deux autres méthodes de l'objet, ok je passe mon cache en mutable, c'est bateau.
Je vous donne un autre exemple, toujours fictif bien que très inspiré, où cette fois c'est beaucoup moins évident.
Mon programme est un lecteur audio style winamp. J'ai une classe Lecteur qui dispose d'une propriété "Position" permettant de savoir à tout moment où en est la lecture.
La mise à jour de Position déclenche un évènement qui demande à l'interface de rafraîchir la barre de progression de la piste audio.
La classe Lecteur implémente l'interface IDataFiller permettant au moteur audio de démander régulièrement des échantillons à envoyer à la carte son. La signature de la méthode à implémenter est : void Fill( char* data, size_t dataSize ) const.
Le lecteur attentif aura remarqué le fameux const 8-)
A priori tout ce qu'est sensé faire le DataFiller (mon Lecteur) c'est de remplir un buffer, donc, pas de souci, la méthode est en droit d'être const.
Seulement le Lecteur veut également en profiter pour mettre à jour la propriété Position parce que, après tout, il a avancé dans la lecture.
Résultat : J'ai une propriété tout à fait légitime de ma classe Lecteur qui doit passer mutable. :(
Je pense que cet exemple est bien plus parlant pour comprendre mon souci d'origine car, cette fois, ce qui doit passer mutable, c'est une variable essentielle et exposée publiquement par la classe Lecteur.
Lorsque JolyLoic parle de la sémantique d'une méthode, j'en suis presque amené à penser que les mécanismes du polymorphisme peuvent changer cette sémantique, qu'elle n'est plus la même en fonction du contexte d'où on l'étudie.
Contexte moteur audio -> méthode Fill n'a qu'un seul but qui ne modifie pas l'objet
Contexte lecteur audio -> méthode Fill a un autre but modifiant l'objet
En fait, la position dans le flux n'est pas une "propriété intrinsèque" du flux de données audio...
Les propriété intrinsèques sont:
- le titre de l'album,
- la durée de l'album
- sa taille (éventuellement)
- les données audio qu'il contient
La position n'est, effectivement - et bien que tu puisse, d'autre part, demander où le flux audio en est de la lecture - qu'une sorte de cache permettant de retrouver l'échantillon suivant à renvoyer.
La constance est une indication sémantique sur la donnée : savoir si une opération va modifier l'état visible de ton objet. Si dans les détails d'implémentation, il y a des choses qui sont altérées (cache et autres évaluations paresseuses, mutex, ...), ben ... ce sont des détails que l'appelant ne perçoit pas.
Désolé, mais comme deux appels à Fill n'ont pas le même effet -- on ne recoit pas les mêmes données -- , l'erreur pour moi est de mettre Fill comme membre const (à voir les membres de basic_istream, ses concepteurs ont le même avis).Citation:
Envoyé par NiamorH
Un Fill qui pourrait être const aurait une interface comme
Code:void Fill(size_t pos, unsigned char* data, size_t size) const;
Bien vu, j'aurais plutôt tendance à me ranger à cet avis.
J'ai l'impression que les choses sont plus claires pour moi sur ce sujet maintenant.
Merci pour vos interventions :)
C'est justement pourquoi dans le cas des conteneurs, les itérateurs sont des objets séparés, et non inclus dans la liste.
Hum je suis pas sûr d'avoir pigé ta remarque Médinoc
Traduction:
Quand tu parcoures une liste chaînée, tu ne stockes pas le pointeur "courant" dans la structure liste elle-même, mais tu le gardes à l'extérieur.
Que ce soit sous la forme d'un itérateur (listes STL) ou autre chose (listes MFC).
Et aussi pour des histoires de ré-entrance et autres accès concurrents.
Et surtout à l'utilisateur ;)Citation:
Envoyé par koala01
Je dirais même au développeur ;)
En fait, non...Citation:
Envoyé par Matthieu Brucher
La valeur d'une fonction constante pour l'utilisateur est - effectivement - purement informative.
Tu peux en effet très bien envisager d'appeler une méthode constante sur un objet qui ne l'est pas.
se voit de manière très commune...Code:
2
3
4
5
6
7
8
9
10
Par contre, c'est si l'objet est constant que cela se corse:
Le compilateur refusera tout appel à une méthode qui ne se sera pas engagée (par sa signature constante) à ne pas modifier l'objet, et cela fait force de loi pour lui.
La déclaration d'une méthode constante s'adresse donc bien en priorité au compilateur ;)Code:
2
3
4
5
6
7
8
9
10
11
Le compilo vérifie des choses avec le const, mais c'est bien avant tout une précision sur l'état visible, donc qui concerne plus l'utilisateur qu'autre chose.Code:
2
3
4
5
6
7
8
9
10
Quand je dis que c'est pour le développeur, c'est que j'ai mes raisons ;)Citation:
Envoyé par koala01
Je renvoie à ce que Herb Sutter dit du mot-clé const, et je suis d'accord avec lui. C'est surtout pour empêcher le développeur de faire n'importe quoi. Mais derrière, le compilateur ne va pas activer des optimisations spécifiques, parce qu'il ne peut pas, à cause des mutable, des pointeurs vers les classes, ...
Il peut en activer certaines quand une fonction const est définie inline, bien sûr.
Ensuite, je pense qu'on doit pouvoir régler le compilo pour qu'il suppose que les fonctions membres const ne font pas de const_cast, permettant des optimisations pour les membres ni pointeurs ni mutables. Si le "Assume no aliasing" existe, une telle option doit exister aussi...
Pas encore trouvé cette option alors, et pourtant, j'ai scanné pas mal d'options de compilateurs ces dernières semaines.
const ou pas const, s'il constate que tout le code est const, il va faire les mêmes choses, les mêmes optimisations. Donc c'est vraiment au développeur de faire attention à bien différentier les deux si le besoin s'en fait sentir.
Et rien n'empeche de faire les memes si la fonction n'est pas const, il doit faire exactement les memes controles.Citation:
Envoyé par Médinoc