Discussion :

[Gaspoute]

[edit]sujet d�terr� : ici [/edit]

Bonjour,

Je d�terre un peu le sujet mais je suis tomb� dessus en faisant une recherche sur Google ^^ Auriez-vous une explication claire du pourquoi de cette erreur ? Dans mon cas, c'est � cause du 'const' qui suit l'un des param�tres de mon op�rateur <<.

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
template <typename M>
class VehiculeElectrique: public VehiculeNonHybride<M> {
public:
	template <typename T>
	friend std::ostream & operator<<(std::ostream &, const VehiculeElectrique<T> &);
};
 
template <typename T>
std::ostream & operator<<(std::ostream & flux, const VehiculeElectrique<T> & vehicule) {
	flux << "Véhicule électrique (" << vehicule.getMoteur() << ")" << std::endl;
        return flux;
}

Merci :-)

[Invit�]

Bonjour,

Ta fonction membre getMoteur() est-elle d�clar�e avec le mot cl� const?

[Gaspoute]

Non, voil� � quoi ressemble ma classe VehiculeNonHybride:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
template <typename M>
class VehiculeNonHybride: public Vehicule {
private:
	M moteur_;
 
public:
	M & getMoteur();
};
 
template <typename M>
M & VehiculeNonHybride<M>::getMoteur() { return moteur_; }

Si j'ajoute 'const' devant getMoteur(), il m'affiche une erreur.

[JolyLoic]

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
 
template <typename M>
M const & VehiculeNonHybride<M>::getMoteur() const { return moteur_; }

[Gaspoute]

Super merci :-)

J'ai une autre question avec l'ajout du 'const'. Pourquoi ceci m'affiche une erreur ?

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
 
template <typename M>
void VehiculeElectrique<M>::demarrer() {
	VehiculeElectrique<M>::getMoteur().allumer();
        std::cout << "Le véhicule démarre" << std::endl;
}

et pas �a

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
template <typename M>
void VehiculeElectrique<M>::demarrer() {
	M moteur = VehiculeElectrique<M>::getMoteur();
	moteur.allumer();
	std::cout << "Le véhicule démarre" << std::endl;
}

J'ai peut-�tre un d�but de r�ponse mais sans �tre s�r: dans le deuxi�me bout de code, on fait un cast lorsqu'on assigne le retour � la variable 'moteur'.

[JolyLoic]

C'est presque �a :

Dans le premier, tu essaye d'appeler allumer sur une r�f�rence constante au moteur contenu par ton v�hicule : Ca ne marche pas.

Dans le deuxi�me, tu dupliques l'objet moteur contenu dans ton v�hicule pour en obtenir un nouveau (cette duplication est une op�ration constante, donc �a passe). Puis tu allumes cette copie, il n'y a pas de soucis.

Mais si tu appelles ensuite getMoteur().estAllume(); (au fait pourquoi mettre VehiculeElectrique<M>:: devant getMoteur() ?), tu pourras voir que le moteur de ton v�hicule est toujours �teint !

[Gaspoute]

Le mieux alors serait de faire une r�f�rence � l'objet stock� par 'moteur_' ?

Je mets 'VehiculeElectrique<M>::' pcq 'getMoteur()' d�pend d'un template. Ou est-ce une erreur ?

Je dois avouer que les templates est un sujet complexe ^^

[Ekleog]

Il te faudrait alors faire deux versions de la fonction getMoteur (enfin, si tu tiens absolument � mettre en place un tel get/setter) :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
const M & getMoteur() const;
M & getMoteur();

Mais ce n'est pas n�cessaire.
En effet, tu es dans la classe VehiculeElectrique<M> (consid�res �a comme une classe, �tant donn� que le fait qu'elle soit template n'a pas d'importance ici).
Ceci a plusieurs cons�quences.
D'abord, tu n'es pas oblig� de mettre VehiculeElectrique<M>:: devant chacun de tes appels � des m�thodes du m�me objet.
Et surtout, tu n'es tout bonnement pas oblig� d'utiliser getMoteur() du tout !
Tu peux utiliser moteur_ tout court.

Ce qui t'am�ne � ceci :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
template <typename M>
void VehiculeElectrique<M>::demarrer() {
	moteur_.allumer();
        std::cout << "Le véhicule démarre" << std::endl;
}

[koala01]

Salut

Il te faudrait alors faire deux versions de la fonction getMoteur (enfin, si tu tiens absolument � mettre en place un tel get/setter) :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
const M & getMoteur() const;
M & getMoteur();

Oh, bon dieu!!! non!!!

Il ne faut jamais cr�er un accesseur non constant ou renvoyant une r�f�rence non constante !!!

Autrement, tu perds tout contr�le sur les modifications que pourra subir ton objet, et, ca, c'est le premier pas sur un chemin qui ne peut te mener que vers un mur

En outre, la pr�sence m�me d'un accesseur (fut il constant ) ne se justifie � priori absolument pas :

Tout v�hicule motoris� va tr�s certainement exposer une s�rie de comportements susceptibles d'agir sur l'�tat du moteur, mais il n'y a aucune raison que l'utilisateur du dit v�hicule n'ait � connaitre le moteur pour �tre en mesure d'utiliser le v�hicule

[JolyLoic]

Oh, bon dieu!!! non!!!

Il ne faut jamais cr�er un accesseur non constant ou renvoyant une r�f�rence non constante !!!

Tu veux dire, comme std::vector<T>::operator[] ?

[koala01]

Tu veux dire, comme std::vector<T>::operator[] ?

Ca, c'est l'exception qui confirme la r�gle, parce que vector a pour seule responsabilit� de regrouper un ensemble d'objets types identique de mani�re contig�e en m�moire

Il n'a donc absolument pas � d�cider s'il est coh�rent ou non de permettre la modification des �l�ments qu'il contient d�j�

Par contre, le fait de permettre d'acc�der au moteur d'un v�hicule et de pouvoir le modifier � sa guise rentre bel et bien dans le cadre de la r�gle g�n�rale qui est : cela n'a aucun sens

[Gaspoute]

Si j'ai bien compris: dans mon cas, la m�thode 'getMoteur()' n'a aucun sens et il serait alors plus judicieux d'utiliser directement l'attribut 'moteur_' de la classe 'VehiculeNonHybride' � l'int�rieur de la classe 'VehiculeElectrique' comme l'a sugg�r� Equinoxe_ pour modifier son �tat comme ici 'moteur_.allumer()' ?

Cependant, admettons que �a soit coh�rent de faire un getter, est-ce pour y acc�der doit-on le faire comme ceci ?

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
 
VehiculeElectrique<M>::getter()

Encore merci de votre aide

[koala01]

Si j'ai bien compris: dans mon cas, la m�thode 'getMoteur()' n'a aucun sens et il serait alors plus judicieux d'utiliser directement l'attribut 'moteur_' de la classe 'VehiculeNonHybride' � l'int�rieur de la classe 'VehiculeElectrique' comme l'a sugg�r� Equinoxe_ pour modifier son �tat comme ici 'moteur_.allumer()' ?

Effectivement, la m�thode getMoteur() n'a aucun sens, et il serait judicieux d'acc�der directement � l'attribut moteur_ de la classe qui dispose de cet attribut

Car j'ose esp�rer que tu ne fais pas d�river ta classe Vehicule hybride de VehiculeElectrique et de VehiculeNonHybride !!!

Les invariants du v�hicule hybride (nombre de moteur(s), par exemple)ainsi que ses pr� et post conditions (�tat du (des) moteur(s) en fonction de la vitesse, par exemple) sont en effet totalement incompatible avec un tel h�ritage multiple (aussi bien du point de vue de vehiculeNonHybride que du point de vue de VehiculeElectrique)

Cependant, admettons que �a soit coh�rent de faire un getter, est-ce pour y acc�der doit-on le faire comme ceci ?

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
 
VehiculeElectrique<M>::getter()

Encore merci de votre aide

Pour autant qu'un accesseur soit opportun, tu y fait appel depuis l'objet sur lequel tu souhaites utiliser l'accesseur, c'est donc plutot du genre de

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
Type obj;
/* voir 
Type<T> obj;
*/
item = obj.getter();
// OU   -   OU   -   OU
obj.getter().doSomething();

[Gaspoute]

Car j'ose esp�rer que tu ne fais pas d�river ta classe Vehicule hybride de VehiculeElectrique et de VehiculeNonHybride !!!

Effectivement, il y a un classe 'VehiculeHybride' dont h�ritent d'autres v�hicules

Ca commence � devenir plus clair, merci
Je reviendrai p-e sur l'un ou l'autre sujet en cas de probl�me ^^

[Ekleog]

Salut
Oh, bon dieu!!! non!!!

Il ne faut jamais cr�er un accesseur non constant ou renvoyant une r�f�rence non constante !!!

Autrement, tu perds tout contr�le sur les modifications que pourra subir ton objet, et, ca, c'est le premier pas sur un chemin qui ne peut te mener que vers un mur

En outre, la pr�sence m�me d'un accesseur (fut il constant ) ne se justifie � priori absolument pas :

Tout v�hicule motoris� va tr�s certainement exposer une s�rie de comportements susceptibles d'agir sur l'�tat du moteur, mais il n'y a aucune raison que l'utilisateur du dit v�hicule n'ait � connaitre le moteur pour �tre en mesure d'utiliser le v�hicule

Je me permettrai de pr�ciser que c'est uniquement si il tient vraiment � mettre en place un tel accesseur. (cf. mon message d'au-dessus)

Mais, en fait, le principe m�me d'un accesseur est devenu � mes yeux �trange (en tout cas, un accesseur direct), cf. http://blog.emmanueldeloget.com/inde...des-accesseurs

[Gaspoute]

J'ai suivi vos conseils et j'ai utilis� directement l'attribut 'moteur_' de ma classe 'VehiculeNonHybride' dont h�rite 'VehiculeElectrique', cependant il m'affiche encore une erreur me signalant que cet attribut n'existe pas.

In file included from projet.cpp:8:
VehiculeElectrique.hpp: In member function �void VehiculeElectrique<M>::demarrer() const�:
VehiculeElectrique.hpp:22: error: �moteur_� was not declared in this scope

Je ne comprends pas pourquoi, pourtant j'ai bien mis l'attribut en 'protected' afin qu'il soit accessible par les classes qui h�ritent de 'VehiculeNonHybride'.

Voici ma classe 'VehiculeElectrique':

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
 
#include <iostream>
#include "VehiculeNonHybride.hpp"
 
template <typename M>
class VehiculeElectrique: public VehiculeNonHybride<M> {
public:
	template <typename T>
	friend std::ostream & operator<<(std::ostream &, const VehiculeElectrique<T> &);
	void demarrer() const;
};
 
template <typename T>
std::ostream & operator<<(std::ostream & flux, const VehiculeElectrique<T> & vehicule) {
	flux << "Véhicule électrique" << std::endl;
	return flux;
}
 
template <typename M>
void VehiculeElectrique<M>::demarrer() const {
	moteur_.allumer();
	std::cout << "Le véhicule démarre" << std::endl;
}

et ma classe 'VehiculeNonHybride':

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
#ifndef VEHICULENONHYBRIDE_H
#define VEHICULENONHYBRIDE_H
 
#include "Vehicule.hpp"
 
template <typename M>
class VehiculeNonHybride: public Vehicule {
protected:
	M moteur_;
};
 
#endif

[JolyLoic]

Pas de bol, tu es tomb� sur le cas sp�cial tordu...

La classe de base est un template, elle pourrait donc �tre sp�cialis�e, donc le compilateur n'a pas le droit de regarder dedans avant de savoir ce que vaut M.

Maintenant, quand on a un nom dans un template, ce nom peut �tre de deux cat�gories : d�pendant ou non d�pendant d'un param�tre template. Les noms non d�pendants sont r�solus imm�diatement, les noms en d�pendant attendent l'instanciation du template pour �tre r�solus (toujours pour ces histoires de sp�cialisation).

A priori, moteur_ ne d�pend pas de ce param�tre, donc il doit �tre r�solu imm�diatement. Par contre, quand on cherche � le r�soudre, on n'a pas le droit de regarder dans la classe de base. Du coup, on ne le trouve pas pendant cette phase.

Solution ? Rendre le nom d�pendant.
Le plus simple est d'utiliser this->moteur_ au lieu de moteur_

Je ne sais pas si j'ai �t� clair, ce n'est pas facile � expliquer le pourquoi du comment...

[Gaspoute]

Je pense avoir compris merci :-)