Discussion :

[gabrielS]

Bonjour a tous,

j'ai une question a propos des references de c++ associees au mot-cle 'const'.

Je vous copie la ligne de code qui me pose probleme :

Code :

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

GUInterface.getCurrentButton().getCurrent().setCurrentShape(IExponential);

(current etant pour le courant/l'intensite dan un circuit electronique).

En faisant retourner a mes getter des class&, cela fonctionne, mais j'aimerai pouvoir m'interdire de modifier cette reference depuis le getter.
J'ai donc remplace le type de mes getter par 'const class&' au lieu de 'class&' et je recupere une erreur a la compil lors de la ligne de code que j'ai mis au dessus.
Je recupere le message d'erreur suivant :

Code :

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

'CurrentButton::getCurrent' : cannot convert 'this' pointer from 'const CurrentButton' to 'CurrentButton &'

Simplement, pour que mon code soit plus propre, j'aimerai juste interdire la modif d'un attribut depuis le getter, mais pouvoir quand meme recuperer une reference vers l'attribut en question, en lui appliquant (ici) la methode setCurrentShape, qui va modifier la shape de courant.

Merci d'avance pour votre aide,

Gabriel

[koala01]

Salut,

De manière générale, il est particulièrement intéressant de faire en sorte que tous les accesseurs ("getters") soient des fonctions constantes qui renvoient des (références sur) des objets constant.

En effet, si tu ne le fais pas, quel intérêt as tu à placer un membre dans l'accessibilité privée si le fait d'invoquer getMachinChose() te permet de modifier le MachinChose obtenu

Pourquoi ne pas, à ce moment là, laisser directement le MahinChose en question dans l'accessibilité publique

De mon coté, je dois t'avouer que je suis très loin d'être particulièrement fan des mutateurs ("setters") pour des raisons très sensiblement similaires

Cependant, il faut avouer que de nombreuses bibliothèques (dont la plupart des bibliothèques graphiques) fournissent un couple getXXX / setXXX pour la quasi totalité de leurs classes, et il faut donc bien pouvoir faire avec

Ceci dit, je ne refuse pas de te répondre, mais, pour que ma réponse soit un minimum cohérente avec ce dont tu dispose, il faudrait quelques informations supplémentaire, comme par exemple (c'est le minimum) le type renvoyé par les fonctions getCurrentButton et getCurrent.

Il faudrait aussi savoir si ce sont des types que tu as créés toi meme ou non, et, si oui, il serait pas mal d'en avoir au minimum la déclaration complète.

Car, l'idée générale serait en fait de prévoir, pour chaque classe "intermédiaire" entre GUInterface et la classe qui présente la fonction setCurrentShape autrement dit, pour ce qui est renvoyé par getCurrentButton et ce qui est renvoyé par getCurrent) un comportement qui permette de "transmettre" l'ordre en question

Ainsi, tu pourrait en arriver à avoir simplement un code proche de

Code :

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

GUInterface.setShapeFprCurrentButton(IExponential);

Maintenant, je ne suis vraiment pas sur qu'il soit réellement du ressort de GUInterface de s'occuper d'aller modifier cette information.

Peut etre (sans doute) devrais tu faire en sorte, si l'information n'est disponible qu'à partir de GUInterface, de la transmettre (sans doute lors de la création) aux classes dont ca serait du ressort de le faire

Et, si la modification doit être effectuée suite à un événement, sans doute devrais tu t'orienter vers les signaux et les slots, afin de pouvoir connecter un slot qui aura pour résultat de connecter la fonction setCurrentShape à un signal qui sera émis par GUInterface

Comme je l'ai dit plus haut, tu ne nous donnes malheureusement pas assez de détails pour nous faire une idée précise, mais j'espère avoir réussi à te mettre sur la voie

[gabrielS]

Hey,

Merci pour ta reponse Koala.
Alors pour etre plus precis, j'ai une GUInterface qui a des objets de type Button, donc par exemple l'objet currentButton (bouton pour le courant).
Celui-ci a un attribut de type 'Courant'. J'ai cree toutes ces classes, donc tous les 'types' sont potentiellement changeables; l'pbjet 'Courant' etant pour l'instant une forme (currentShape - pour avoir la forme du signal), une periode et une amplitude.

Je suis bien d'accord avec toi sur le fait que dans aucun ca ne doit pas etre GUI qui appelle le setCurrentShape().
Le pb est que pour le moment, la GUi a le CurrentButton qui a le Current et donc je passe par ici.
Serait-il peut etre plus judicieux d'avoir que les Button dans GUI et le 'Current' dans une autre classe de type InputOutput qui regroupent toutes les 'variables non GUI' de la gui ?

Peut etre (sans doute) devrais tu faire en sorte, si l'information n'est disponible qu'à partir de GUInterface, de la transmettre (sans doute lors de la création) aux classes dont ca serait du ressort de le faire

Je pense que je peux rendre l'information disponible depuis justement une sorte de classe InputOutput dont un clic sur un des button de la GUI reveillerait potentiellement l'inputOutput concerne.

Et, si la modification doit être effectuée suite à un événement, sans doute devrais tu t'orienter vers les signaux et les slots, afin de pouvoir connecter un slot qui aura pour résultat de connecter la fonction setCurrentShape à un signal qui sera émis par GUInterface

C'est exacement ce que je veux faire - repondre a l'evenement 'clic sur currentButton' - Peux tu donner plus d'informations pour connecter 2 classes de facon propre avec un signal emis par GUInterface pour la [future] classe InputOutput ?

Merci d'avance,

Gabriel

[r0d]

Bonjour,

ce que tu cherches à appliquer c'est un principe qui s'appelle la const-correctness (que l'on trouve parfois en français sous "const-conformité"). C'est une très bonne pratique, et je t'encourage à persévérer dans cette voie.

Dans ton cas précis, c'est difficile à dire ce qu'il se passe car tu donnes peu de détails. Mais dans toute ta chaîne:

Code :

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

GUInterface.getCurrentButton().getCurrent().setCurrentShape(IExponential);

il faut que tous ces appels respectent la const conformité sinon la chaîne ne passe pas. Par exemple, si getCurrent() retourne un const Truc& alors tu ne peux appeler que les fonctions membres constantes de Truc. Donc basiquement, si getCurrent() retourne un const Truc&, mais que setCurrentShape() n'est pas const, alors ça ne marche pas. Or, un setter n'a pas a être const, puisqu'il est sensé modifier l'instance qui l'appelle.

[r0d]

Je suis bien d'accord avec toi sur le fait que dans aucun ca ne doit pas etre GUI qui appelle le setCurrentShape().
Le pb est que pour le moment, la GUi a le CurrentButton qui a le Current et donc je passe par ici.
Serait-il peut etre plus judicieux d'avoir que les Button dans GUI et le 'Current' dans une autre classe de type InputOutput qui regroupent toutes les 'variables non GUI' de la gui ?

Je pense que je peux rendre l'information disponible depuis justement une sorte de classe InputOutput dont un clic sur un des button de la GUI reveillerait potentiellement l'inputOutput concerne.


C'est exacement ce que je veux faire - repondre a l'evenement 'clic sur currentButton' - Peux tu donner plus d'informations pour connecter 2 classes de facon propre avec un signal emis par GUInterface pour la [future] classe InputOutput ?

Il existe des solutions toutes prêtes qui répondent à toutes ces questions. Certainement la plus connue est le MVC. En gros, l'idée est de bien séparer les problèmes: d'un côté tu as l'interface graphique, de l'autre les données, et enfin les comportements (controller).
Si tu débutes, tu peux simplifier et garder seulement le modèle (que l'on voit parfois sous l'appellation de "classes métiers") et la view (l'interface graphique dans ton cas).

En gros, tu aura tes données dans ton Modèle (dont le currentbutton, qui sera représenté par un ID ou un quelconque identifiant), et ton IHM se contentera d'afficher le contenu du Modèle.

Les détails d'implémentations dépendent des bibliothèques que tu utilises, en particulier pour l'IHM, mais en gros l'idée c'est:
- d'un côté le modèle qui contient les données
- de l'autre l'IHM qui affiche, à chaque frame ou par un système d'update, les données

Pour tester si ton programme est bien conçu, que ces deux parties sont bien séparées, tu dois pouvoir désactiver l'un ou l'autre sans que le programme ne plante (il ne fera rien, mais il ne plantera pas).

[gabrielS]

Merci, oui en effet c'est le terme de const-correctness qui m'etait inconnu. J'ai pu resoudre mon probleme en empechant a ma GUI de modifier quoique ce soit au modele (oui c'etait pas propre )

Bref, merci pour vos reponses, qui m'ont debloquees !