Discussion :

[coyotte507]

Bonjour,

j'ai récemment installé Linux, et g++ (version 4.2), et en compilant ce programme:

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>
 
template <class T>
class smart_ptr
{
public:
    T data;
	int i;
 
	virtual int get_data() { return i; }
};
 
template <class T>
class wrapper : public smart_ptr<T>
{
	virtual int get_data() {return i; }
};
 
int main()
{
	std::cout << "Hello world!" << std::endl;
	return 0;
}

J'ai une erreur: "i was not declared in this scope" pour la fonction get_data() de wrapper.

Si au lieu de mettre public: smart_ptr<T> je mets un type non template tout va bien (mais j'ai besoin des templates!!)

Pour réussir à le faire passer je dois faire:

Code :

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

1
2
3
4
5
template <class T>
class wrapper : public smart_ptr<T>
{
	virtual int get_data() {return smart_ptr<T>::i; }
};

C'est moche!

Est-ce que j'ai loupé une option de compilation quelque part, parce que je trouve ça vraiment louche?

Merci

[thoratou]

Ah mon avis, le compilateur Linux veut se protéger d'une spécification de smart_ptr ne possédant pas d'attribut public i. Typiquement :

Code :

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

1
2
3
4
5
6
7
 
template<>
class smart_ptr<maClasse>
{
public:
	virtual int get_data() { return 1; }
};

Il demande ainsi d'indiquer explicitement d'où provient la variable i et laisse donc la responsabilité au programmeur de ne spécifier que des smart_ptr avec un attribut i.

[Alp]

Ah mon avis, le compilateur Linux veut se protéger d'une spécification de smart_ptr ne possédant pas d'attribut public i. Typiquement :

Code :

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

1
2
3
4
5
6
7
 
template<>
class smart_ptr<maClasse>
{
public:
	virtual int get_data() { return 1; }
};

Il demande ainsi d'indiquer explicitement d'où provient la variable i et laisse donc la responsabilité au programmeur de ne spécifier que des smart_ptr avec un attribut i.

Tout à fait.
Et si tu te sers de i à plusieurs endroits, un :

Code :

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

using smart_ptr<T>::i;

à l'intérieur de la déclaration de la classe devrait faire l'affaire, pour que tu n'ais plus à écrire "smart_ptr<T>::" devant à chaque fois.

[Pragmateek]

Et avec :

Code :

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

1
2
3
4
5
template <class T>
class wrapper : public smart_ptr<T>
{
	virtual int get_data() {return this->i; }
};

?

[thoratou]

C'est toujours la même chose.

Le compilateur a besoin de "passer un contrat" disant :

Je vais chercher l'attribut i de smart_ptr seulement si tu m'assures que smart_ptr contiendra toujours un attribut i. Ce contrat est passer dans les 2 cas présentés précédemment :

Code :

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

return smart_ptr<T>::i;

ou

Code :

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

using smart_ptr<T>::i;

dans ces 2 cas, si tu spécifies un smart_ptr sans un attribut i, tu auras une erreur de compilation.

Le compilteur Visual est "malheureusement" plus souple, et il résoudra explicitement ce genre de dépendance sans "passer de contrat". Imagine maintenant le cas suivant :

Code :

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

1
2
3
4
5
6
 
template <class T>
class wrapper : public smart_ptr<T>, public autreClasse<T>
{
	virtual int get_data() {return i; }
};

Dans ce cas avec héritage multiple, on ne peut pas savoir d'où provient i.
Alors qu'en ecrivant ceci :

Code :

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

1
2
3
4
5
6
7
 
template <class T>
class wrapper : public smart_ptr<T>, public autreClasse<T>
{
	using smart_ptr<T>::i;
	virtual int get_data() {return i; }
};

le contrat est passé, on s'engage à ce que smart_ptr possède systématiquement un attribut i

EDIT :
Je ne parle pas de contrat par hasard, c'est à relier à la programmation par contrat. Il doit exister de nombreux cours, notamment sur le langage Ada est parfait pour apprendre la programmation par contrat.

En C++, il y a des manques :
- Absence d'un mot clef type 'interface' en Java. Beaucoup de développeurs C++ sont passé par le java et reprennent donc le même concepts avec les classes dites 'abstraites pures'
- Absence de contrat pour les types paramétrés dans la syntaxe du langage. Les compilateurs s'arrangent, ce qui donne les différences obtenues ici entre Visual et Linux. Le nouveau standard C++0x devrait rectifier le tir avec la notion de 'concept'.

[Montag]

Pour moi la meilleure solution reste celle de seriousme. C'est d'ailleurs cette dernière qui est préconisé dans "C++ Templates: The Complete Guide".

PS: pour ceux que ça intéresse je conseille la lecture du post de James Kanze dans ce thread

[coyotte507]

Merci, le "using" est une solution acceptable

Mais sur ce coup-là je trouve que Visual est bien meilleur, d'ailleurs si g++ ne s'occupait que des template qui sont initialisés dans le code (initialisation paresseuse) au lieu de faire dans le générique il n'y aurait aucun problème...

Et puis même dans le générique il est dans un cas dans lequel il peut tout déterminer, et ne devrait lancer une erreur que dans le cas d'une ambiguïté .

En tout cas merci de vos réponses, problème résolu

[Alp]

- Absence de contrat pour les types paramétrés dans la syntaxe du langage. Les compilateurs s'arrangent, ce qui donne les différences obtenues ici entre Visual et Linux. Le nouveau standard C++0x devrait rectifier le tir avec la notion de 'concept'.

Raté, vas voir dans C++ > Communauté.
Ca sera éventuellement dans celui d'après...

[Goten]

He ben non... les concepts on était retiré de la prochaine norme .

[thoratou]

Pour répondre à MonTag, la solution du this ne me semble pas la meilleure

Si on reprend le cas de l'héritage multiple avec chacun des parents possédant un attribut i, le this ne permettra pas de déterminer lequel est utilisé.
Autant prendre directement les bonnes habitudes.

Par contre c'est vraiment dommage pour les concepts, je pense que ça aurait été une bonne chose

[Montag]

Pour répondre à MonTag, la solution du this ne me semble pas la meilleure

Si on reprend le cas de l'héritage multiple avec chacun des parents possédant un attribut i, le this ne permettra pas de déterminer lequel est utilisé.
Autant prendre directement les bonnes habitudes.

Par contre c'est vraiment dommage pour les concepts, je pense que ça aurait été une bonne chose

Et quand le nom de la classe de base est super long tu fais quoi ? Tu vas écrire à chaque fois ma_classe_de_base<T, R, S>::member ? Franchement c'est horrible, le C++ est déjà suffisamment verbeux sans en plus en rajouter. D'ailleurs une recherche rapide dans le code de boost me conforte dans l'idée que le this-> est la meilleure solution.
Imagine que l'auteur de ce code (tiré de boost::asio) ait été de ton avis ...

Code :

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

1
2
3
4
5
6
7
template <typename Protocol, typename Reactor>
class reactive_socket_service
  : public boost::asio::detail::service_base<
      reactive_socket_service<Protocol, Reactor> >
{
...
};

Quand à l'argument sur l'héritage multiple je ne vois pas trop où tu veux en venir. Que préconises-tu ? De qualifier le membre d'une classe base à chaque fois que l'on veux y accéder ?

[coyotte507]

Il y a quelque chose qui me chiffonne

Si le compilateur est content avec un this-> (qui ne précise pas du tout d'où vient la variable), alors pourquoi sans le this-> ça ne marche pas? Pour avoir des messages d'erreurs plus explicites?

Sinon:

Tu vas écrire à chaque fois ma_classe_de_base<T, R, S>::member ?

thoratou a aussi proposé cette solution:

Code :

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

using smart_ptr<T>::i;

Enfin bref pour en revenir au problème dans mon cas en pratique chaque classe dérivée appelait des paramètres template différents (le plus souvent dérivés des paramètres templates de la classe de base) donc l'héritage ne servait pas à grand chose vu la manière dont le code était dupliqué. (j'ai quand même fait une classe de base ultra-basique sans templates, mais c'est tout)

Mais j'aurais appris quelque chose

[Montag]

Il y a quelque chose qui me chiffonne

Si le compilateur est content avec un this-> (qui ne précise pas du tout d'où vient la variable), alors pourquoi sans le this-> ça ne marche pas? Pour avoir des messages d'erreurs plus explicites?

Dans mon premier message j'ai donné un lien vers un thread dans lequel James Kanze explique très bien le problème.

thoratou a aussi proposé cette solution:

Code :

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

using smart_ptr<T>::i;

Bof, injecter des noms dans le scope de la classe dérivée j'aime pas trop.

[thoratou]

le problème avec le this est que le compilateur fait une sorte de cast implicite pour trouver d'où vient l'attribut.
Par exemple ici le this est casté de const wrapper<T> const * en const smart_ptr<T> const *.

Ce genre de mécanisme est à prohiber : un contrat doit être correctement explicité, même si le C++ est un peut casse gueule pour se genre de chose

Dans le cas d'héritage multiple avec 2 classes héritées possédant un attribut i, quelle attribut sera choisi ?
Réponse : ça dépend de l'implémentation du compilateur, puisque c'est lui qui décide du cast à effectuer (ou éventuellement il peut faire un joli message d'erreur).

La solution smart_ptr<T>::i (avec ou sans using) est la seule sans ambiguïté et avec un contrat clairement explicité.

Et effectiviement, même si le nom de la classe est super long, je met quand même le nom plutôt qu'un this.

Après si ca te suffit de te contenter de la réponse "c'est machin bidule qui a écrit ça dans son livre", alors continue avec this

[Montag]

Je ne sais pas d'où tu sors tes histoires de cast implicite ni de quel contrat tu veux parler mais bon...
En ce qui concerne l'héritage multiple je ne comprends toujours pas ton argument. Quand, dans une méthode d'une classe dérivée, tu fais référence à un membre d'une classe de base tu le qualifies systématiquement ?

Toujours est-il que je continuerai à utiliser this-> non pas comme tu le prétends parce que je l'ai lu dans un livre mais bien parce que cette solution me parait être la plus élégante.

[thoratou]

Bon je vais alors faire un exemple complet :

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
 
template <class T>
class smart_ptr{
public:
    int i;
    ....
};
 
 
template <class T>
class autreClasse{
public:
    int i;
    ....
};
 
template <class T>
 
template <class T>
class wrapper : public smart_ptr<T>, public autreClasse<T>{
    virtual int get_data() {return this->i; }
};

Peut-tu me dire quel attribut i sera utilisé ?

[Klaim]

Ca ne compilera même pas non? Autrement dit l'erreur est difficile a rater dans ce genre de cas. - VC9 me donne bien une erreur d'ambiguïté sur i.

Il n'y a que si il y avait un i dans un scope plus proche (membre ou locale) que l'ambiguité serait automatiquement résolue.

[thoratou]

Exactement, d'où le smart_ptr<T>::i plutôt que this->i

Dans le cas de smart_ptr<T>::i, pas d'ambiguïté

[Montag]

Bon je vais alors faire un exemple complet :

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
 
template <class T>
class smart_ptr{
public:
    int i;
    ....
};
 
 
template <class T>
class autreClasse{
public:
    int i;
    ....
};
 
template <class T>
 
template <class T>
class wrapper : public smart_ptr<T>, public autreClasse<T>{
    virtual int get_data() {return this->i; }
};

Peut-tu me dire quel attribut i sera utilisé ?

Evidemment que dans le cas de l'héritage multiple ça ne fonctionnera pas. Le problème c'est que tu utilises le cas de l'héritage multiple pour justifier l'emploi de smart_ptr<T>:: dans le cas de l'héritage "simple" et là, je ne suis pas d'accord. En effet si on suit tes conseils il faudrait faire ça :

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
class Base
{
public:
    int i;
    ....
};
 
class Derived : public Base
{
public:
    int get_i()
    {
        return Base::i;
    }
};

Et ça c'est...

[thoratou]

... inutile

Dans ce cas d'heritage simple, le contrat est explicité : "je suis la classe Derive, je suis sûr que Base possède un attribut i puisque Base est clairement défini".

Dans le cas avec patron, on peut spécifier n'importe quelle spécialisation de la classe, ne possèdant eventuellement pas d'attribut i. Dans ce cas là, la contrat n'est pas explicité, d'où le smart_ptr<i>::i qui dit "on oblige que toutes définitions de smart_ptr possède un attribut i".