Discussion :

[gilloddon]

Bonjour,

Je viens vers vous car j'ai un petit problème de passage de paramètre dans une méthode, et probablement aussi un petit problème de conception.

Pour simplifier, disons j'ai une classe centrale "App" qui a de nombreux traitements à faire et qui est liée à mon Affichage (Ligne de commande, ou Graphique). Elle reçoit donc les évènements des vues.
Etant donné qu'il y a tout un tas de traitements différents, la classe App instancie dans son constructeur plusieurs classes comme par exemple "CloudModule" pour séparer les traitements par "type".
La classe CloudModule a elle-même pas mal de traitements à faire et instancie aussi dans son constructeur plusieurs classes comme par exemple "FileManager".

La classe App est centrale, délègue un traitement à son module, qui déléguera aussi son traitement à un de ses Managers.
Une classe module contient tous les attributs nécessaire pour les traitements (Buffer, entiers, ...).
Les managers ont besoins des attributs du Module pour effectuer leurs traitements.

Voici un petit diagramme de classe simplifié : http://i.imgur.com/ueKTZTV.png



Mon problème se situe entre les "Modules" et les "Managers".
Au début, je me suis dis que je passerais la référence du "Module" à chaque "Manager" en l'instanciant.
Le Manager pourrait ensuite avoir accès aux attributs via la référence du module.

Mais j’ai un problème en faisant ça, à la compilation : error: no matching function for call to 'FileManager::setModule(CloudModule* const)'

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
    class CloudModule
    {
        public:
            CloudModule();
            virtual ~CloudModule();
 
        private:
            FileManager fileManager;
    };
 
 
 
    CloudModule::CloudModule()
    {
        this->fileManager = new FileManager();
 
        this->fileManager->setModule(this);
    }

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
    class FileManager
    {
        public:
            FileManager();
            virtual ~FileManager();
 
            void setModule(CloudModule *);
 
        protected:
            CloudModule *module;
    };
 
 
 
    FileManager::FileManager()
    {
 
    }
 
    FileManager::~FileManager()
    {
 
    }
 
 
    void FileManager::setModule(CloudModule *aModule)
    {
        this->module = aModule;
    }

J'ai essayé de jouer avec les 'const' dans les paramètres de ma méthode, mais j'arrive pas à passer 'this' non plus si je modifie le prototype de ma méthode.

Code :

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

1
2
3
error: no matching function for call to 'FileManager::setModule(CloudModule* const)'
note: candidate is:
note: void FileManager::setModule(const CloudModule*)

Du coup, je commence aussi à douter, au niveau conception, de la propreté de cette solution.
Est-ce vraiment une bonne façon de répartir des traitements vers plusieurs autres classes ?

Comment est-ce que je pourrais améliorer ce système ?


Merci d'avance.

[foetus]

Réponse vite-faite :

1. Supprime tous les "this->": cela surcharge inutilement
2. Le compilateur te dit ton erreur "FileManager::setModule(CloudModule* const)". Si je ne me trompe pas, tu passes this qui est constant alors que ton prototype lui dit "je peux modifier le paramètre". Donc essaye soit de mettre const dans le prototype si cela est possible soit de caster (le mieux c'est const_cast)

[Ehonn]

setModule est une méthode donc elle connais déjà this.
Tu n'as peut être pas besoin de passer un paramètre ici ?

Dans le code que tu donnes, il y a le constructeur de CloudModule et les déclarations de la classe FileManager.
Du coup, on a pas le prototype de la méthode CloudModule::setModule (qui devrait être selon le code void setModule(CloudModule const *)).

En tout cas, le const_cast est plus qu'à éviter.

[gilloddon]

setModule est une méthode donc elle connais déjà this.
Tu n'as peut être pas besoin de passer un paramètre ici ?

Dans le code que tu donnes, il y a le constructeur de CloudModule et les déclarations de la classe FileManager.
Du coup, on a pas le prototype de la méthode CloudModule::setModule

J'ai modifié mon premier message pour compléter les balises codes, car tu as fais une petite erreur d'interprétation :
La méthode setModule n'est pas dans la classe CloudModule, mais dans la classe FileManager (sinon effectivement, ça ne servirait à rien car CloudModule se connait elle-même ^^).
=> FileManager::setModule(CloudModule *)

qui devrait être selon le code void setModule(CloudModule const *)

C'est la première chose que j'ai essayé quand je me suis aperçu que 'this' était constant, mais ça n'arrange pas les choses.

Code :

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

1
2
3
error: no matching function for call to 'FileManager::setModule(CloudModule* const)'
note: candidate is:
note: void FileManager::setModule(const CloudModule*)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
class FileManager
    {
        public:
            FileManager();
            virtual ~FileManager();
 
            void setModule(CloudModule const *);
 
        protected:
            CloudModule const *module;
    };
 
 
 
    FileManager::FileManager()
    {
 
    }
 
    FileManager::~FileManager()
    {
 
    }
 
 
    void FileManager::setModule(CloudModule const *aModule)
    {
        this->module = aModule;
    }

Sinon, en dehors de ce problème de 'const', est-ce une bonne idée de passer des références de 'this' dans ce cas là ?
Est-ce qu'il existe des solutions plus efficace/plus propres pour répartir ?

[Iradrille]

(le mieux c'est const_cast)

Pour le reste de ta réponse on est d'accord.
Mais on utilise un const_cast quand une erreur de const-correctness à été commise dans du code que l'on doit utiliser mais que l'on ne peut pas corriger.
(Normalement avec le mot clef mutable, il n'y à pas d'autre utilisation possible de const_cast).

Par exemple une ancienne lib C qui prend un char* au lieu d'un const char* en paramètre. (Ou cas similaire).

[foetus]

Mais on utilise un const_cast quand une erreur de const-correctness à été commise dans du code que l'on doit utiliser mais que l'on ne peut pas corriger.
(Normalement avec le mot clef mutable, il n'y à pas d'autre utilisation possible de const_cast).

Pour moi, le const_cast remplace le cast "à la C" pour un usage spécifique (retirer l'état contant) avec une syntaxe (comme les 2-3 autres cast C++) qui te surcharge ton code afin d'alerter le développeur: "Soit tu mets trop de const, soit tes const sont mal faits, soit il y a un truc qui cloche"

[Bousk]

C'est vraiment là ton seul code et c'est bien CE setModule qui plante ? impossible.
Il n'y a aucune raison de planter, dans le contstructeur, this n'est pas const
D'ailleurs ce code compile parfaitement, moyennant l'ajout du * dans la déclaration du membre fileManager de CloudModule.

[Iradrille]

Pour moi, le const_cast remplace le cast "à la C" pour un usage spécifique (retirer l'état contant) avec une syntaxe (comme les 2-3 autres cast C++) qui te surcharge ton code afin d'alerter le développeur: "Soit tu mets trop de const, soit tes const sont mal faits, soit il y a un truc qui cloche"

Oui un const_cast remplace les cast "style C", tout comme static_cast ou reinterpret_cast (dynamic_cast est différent).

Mais dans les cas d'utilisation que tu donne "Soit tu mets trop de const" est faux, ça devrait plutôt être "Il manque un const quelque part".

[Ehonn]

FileManager::setModule(CloudModule * const) et FileManager::setModule(CloudModule const *) sont différents.
Dans le premier, on a pas le droit de modifier le pointeur, dans le deuxième on a pas le droit de modifier l'objet pointé.
(L'utilisation d'une référence permet de ne pas faire ce genre d'erreur).