Discussion :

[jmeuf]

Bonjour,
je suis en train de compiler le code suivant:

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
#include <vector>
 
template <class T>
class ListModule
{
    public:
        ListModule();
        ~ListModule();
 
    protected:
 
    private:
        vector<T>   _List;
        vector<T>::iterator _It;  // << l'erreur est ici
};

et je recupere le message d'erreur a la compilation:
Error : expected ';' before "_It"

Le domaine std est bien resolu (la declaration du vecteur 'vector<T> _List;' compile correctement).

Le compilateur que j'utilise est mingw sous IDE CodeBlocks.

Quelqu'un aurait-il une idee?

Merci.

[Laurent Gomila]

Ajoute typename devant la déclaration. Pour plus d'infos, c'est expliqué dans la FAQ.

[jmeuf]

Nickel! Ca fonctionne, super.

J'aurais jamais trouvé... Comme quoi, il reste encore une bonne part de 'non determinisme' en progra!! On a beau lire des bouquins...

Je vais m'attaquer a tes tutos avec plaisir.

Merci beaucoups.

[Laurent Gomila]

N'oublie pas de cliquer sur

[koala01]

Salut,

Il y a juste une remarque que tu as faite et qui me chagrine...

Il s'agit de

Le domaine std est bien resolu

Heuu... est-ce à dire que tu as une directive

Code :

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

using namespace std;

qui traine, quelque part, dans un de tes fichiers d'entetes

(comme tu présente une déclaration de classe, je crains fortement que ce fut le cas )

Si c'est le cas, sache que c'est une pratique généralement peu recommandable que de mettre la directive dans le fichier d'entete...

[jmeuf]

Je suis d'accord avec toi et ai de suite corrige. C'est 'plus parlant' de laisser apparent l'operateur de resolution (sauf peut-etre pour les cout/endl repetes ... ).

Merci encore pour ton support.

[koala01]

Je suis d'accord avec toi et ai de suite corrige. C'est 'plus parlant' de laisser apparent l'operateur de resolution (sauf peut-etre pour les cout/endl repetes ... ).

Merci encore pour ton support.

A vrai dire, ce n'est pas uniquement parce que c'est plus parlant...

C'est surtout parce que, bien que je ne remette pas en cause l'utilité des directives using, il s'agit de nouveau d'une possibilité qui doit etre utilisée avec "parcimonie", ou, en tous cas, dans une portée restreinte...

Or, il se fait que, sauf erreur, son emploi dan un fichier d'entete va provoquer le fait qu'elle sera active dans tous les fichiers qui incluent, fusse indirectement, le fichier d'entete dans lequel elle se trouve...

Alors, bien que l'exemple soit peut etre excessif...

Imaginons simplement que je crées une bibliotheque qui utilise des classes nommées string, vector ou autres classes tellement connues dans la STL, qui n'ont rien à voir avec les classes de la STL...

Si je choisis ces noms, c'est tout simplement parce que cela correspond à l'usage fait, et, comme j'ai pris la peine de mettre toutes ces classes dans un espace de nommage particulier (p.e: malib), je suis normalement assuré qu'elles n'entrent pas en conflit avec celles de la STL...

Seulement, voilà... toi, en tant qu'utilisateur de ma bibliotheque, tu l'utilise en parallele avec la STL, et c'est ton plus stricte droit...

Et du coup, dans un fichier d'entete dans lequel tu as besoin des std::string, tu inclue le fichier <string> et tu utilise la directive using namespace std;

Dans un autre fichier d'entete dans lequel tu a besoin de ma classe string, tu inclu l'entete correspondant, et tu utilise la directive using namespace malib;...

Et quand tu vas regrouper les deux fichiers d'entetes, ca va coincer...

Simplement parce que quand tu va simplement déclarer string str, il y aura conflit: quelle classe doit etre utilisée: std::string ou malib::string

Et le conflit apparaitra, sauf erreur, systématiquement dans tous les fichiers qui regrouperont les deux fichiers d'entete...

C'est la raison pour laquelle il est très largement conseillé d'utiliser les directives using dans une portée aussi restreinte que possible, et, en tout état de cause, au maximum dans une unité de compilation