Problème classe Console

Version imprimable

02/11/2013, 21h12
solitrion

Problème classe Console
Bonjour tout le monde
voila je veux bien utiliser la classe Console ,
mais quand par exemple j'utilise une méthode de cette classe comme :

Code:

Console::SetWindowSize( 40, 20 );

j'ai une erreur :
```
'Console' has not been declared 
```
je veux bien savoir comment l'utiliser ou la déclarer

merci d'avance
02/11/2013, 23h29
koala01
Salut, et bienvenue sur le forum.

Ce message t'indique, simplement, que le compilateur ne connait pas la classe Console.

Il faut en effet savoir que le compilateur va travailler un peu à la manière dont tu lirais un livre:

Pour chaque fichier d'implémentation (typiquement les fichiers dont l'extension est *.cpp, bien qu'il existe d'autres extensions possibles ;)), il va lire le code de la première ligne à la dernière.

Et tout comme toi, tu ne sais pas ce qui se passe à la page 12 d'un livre lorsque tu en es à la page 10, le compilateur ne sait pas ce qui se trouve à la ligne 12 d'un fichier lorsqu'il se trouve à la ligne 10.

Et comme il "oublie" de manière systématique tout ce qu'il a fait pour le fichier qu'il vient de traiter lorsqu'il passe au fichier suivant, il faut donc s'assurer qu'il connait tout ce que l'on va essayer d'utiliser avant qu'il ne rencontre l'utilisation de quelque chose qu'il ne connait pas.

C'est dans cette optique que l'on sépare généralement le code en deux fichiers bien distincts :

Un fichier d'en-tête (qui prendra, classiquement, l'extension *.h ou *.hpp) qui permet au compilateur connaitre quelque chose et un fichier d'implémentation qui permet d'indiquer au compilateur "ce qui doit être fait".

Ce message peut avoir deux origines bien distinctes:

Soit tu as oublié d'inclure le fichier d'en-tête qui contient la définition de ta classe Console.

Soit tu te trouves dans une situation dans laquelle tu as ce que l'on appelle une dépendance cyclique : une classe A qui doit connaitre une classe B qui doit elle meme connaitre la classe A.

La solution pour la première possibilité est relativement simple : il "suffit" d'inclure le fichier d'en-tête correspondant (Console.hpp :question:) avant d'essayer d'utiliser la classe Console.

La solution pour la deuxième possibilité consiste à utiliser les déclarations anticipées.

Notes enfin que C++ est un langage dit "sensible à la casse" : le mot "console" (tout en minuscule) est considéré comme étant différent du mot "Console" (avec un C majuscule)...

Si tu as défini une classe console et que tu essayes de l'utiliser sous le nom de Console, le compilateur ne pourra pas faire le rapprochement entre les deux ;)

[EDIT]Notes au passage que:
1- Le compilateur est une bestiole étrange, qui nous noie régulièrement sous une tonne de "fausses erreurs" lorsqu'il a "perdu les pédales".

Généralement, il rencontre une première erreur (un ; ou un } manquant) et "perd les pédales", ce qui fait qu'il ne reconnait plus rien du code qui suit.

Il faut donc généralement veiller à traiter en priorité les premières erreurs qu'il indique, car il y a "de fortes chances" pour que les erreurs suivantes ne soient que de "faux positifs" dus aux premières.

2- Le code que tu présentes n'est pas forcément faux, mais je serais d'une certaine manière malgré tout assez surpris qu'il soit correct :aie:

L'appel de la fonction tel que tu l'écris ne sera en effet valide que si la fonction SetWindowSize est une fonction statique de la classe Console.

Autrement dit, cela signifie que tu ne peux définir qu'une taille qui sera commune à l'ensemble des différentes instances de la classe Console.

C'est peut être le cas, mais il y a "fort à parier" que cette fonction permette surtout de préciser la taille de la fenêtre de manière indépendante pour chaque instance de la classe Console.

Dans ce cas, tu devrais en réalité passer par la variable de type console dont tu disposes (normalement).

Ton code risques donc de devoir ressembler d'avantage à quelque chose comme
Code:

1 2 /* soit une variable nommée cons qui est de type Console */ cons.SetWindowSize( 40, 20 );
voire, si la variable en question est un pointeur, à quelque chose comme
Code:

1 2 /* soit un pointeur vers un objet de type Console et appelé ptr */ ptr->SetWindowSize( 40, 20 );
[/EDIT]
02/11/2013, 23h59
solitrion

merci énormément

I learned a lot from that answer :p

Je crois que mon prob c'est que je ne peut pas inclure le fichier <console.h>
l'erreur que je reçois est : no such file or directory .

:s

Citation:

Envoyé par solitrion

merci énormément

I learned a lot from that answer :p

Je crois que mon prob c'est que je ne peut pas inclure le fichier <console.h>
l'erreur que je reçois est : no such file or directory .

:s

Alors, là, il faut déjà faire attention à la casse du nom du fichier à inclure: console.h est (sous certains systèmes d'exploitation du moins) différent de Console.h.

La première chose est donc de vérifier si tu as correctement orthographié le nom du fichier que tu essaye d'inclure (y compris, et surtout, les éventuelles majuscules).

La deuxième chose à faire est de t'assurer que le compilateur connaisse le chemin d'accès au dossier dans lequel le fichier d'en-tête se trouve.

Si tu ne dis rien au compilateur, il va essayer de trouver les fichiers d'en-tête dans un nombre finalement très limité de dossiers:

quelques dossiers qui sont connu pour contenir les fichiers d'en-tête "standard" et
le dossier dans lequel se trouve le fichier .cpp qu'il est occupé à compiler.
Le problème, c'est que les projet sont souvent organisés de manière à séparer les fichiers d'en-tête (qui se trouvent bien souvent dans un dossier nommé "include")et les fichiers d'implémentation (qui se trouvent bien souvent dans un dossier nommé "src").
Une arborescence "classique" pourrait donc prendre la forme de
Code:

1 2 3 4 5 6 7 8 9 dossier "racine" du projet |-> bin | c'est le dossier dans lequel s'effectue la compilation |-> include | |->Console.h | |-> les autres fichiers .h |->src | |->Console.cpp | |-> les autres fichiers .cpp
|->d'autres dossiers éventuels
Evidemment, si tu ne précise pas au compilateur que

Citation:

Ah, au fait, tu trouveras les fichiers d'en-tête dans le dossier include

il n'ira pas les chercher de lui-même.

Généralement, pour ajouter un dossier dans lequel le compilateur doit aller chercher après les fichiers d'en-tête, on utilise l'option I<chemin/vers/le/dossier_en_question> (il s'agit du i majuscule :D).

Avec Gcc, par exemple, si tu te trouves dans le dossier bin (car c'est là que se fait la compilation) et que tu veux compiler Console.cpp, tu devrais utiliser la commande

Code:

g++ -c ../src/Console.cpp -o Console.o -I../include

Après, il y a énormément de choses qui dépendent de l'EDI éventuellement employé et / ou de la manière dont tu automatises la compilation.

Il est toujours utile de vérifier les options de compilation que ton EDI aura définies par défaut, afin, entre autres, de t'assurer qu'il a bel et bien rajouté le dossier qui contient les fichiers d'en-tête dans les options de compilation.

Mais ca, ca se fait de manière spécifique à l'EDI (chacun planquant ces informations où bon lui semble :D), et je ne pourai pas t'en dire plus tant que je ne saurai pas lequel tu utilise :P

Enfin, si tu n'utilises pas d'EDI mais uniquement un système d'automatisation de la compilation comme cmake ou comme les Makefile, il faudra t'intéresser à la manière de rajouter les chemins utilisés pour la recherche des fichiers d'en-tête.

Cela passe généralement par le fait de rajouter l'option adéquate au niveau de variables ou comme CPP_FLAGS ;)

03/11/2013, 01h57
solitrion

J'ai comris :D

j'ai comme IDE qt 5.1.1 , compilateur Mingw 4.8 32bit , comme OS windows 8

je me suis cassé la téte pour retrouver include qui contient console , ou src qui contient console.cpp

est ce que vous avez une idée

merci beaucoup

Citation:

Envoyé par solitrion

J'ai comris :D

j'ai comme IDE qt 5.1.1 , compilateur Mingw 4.8 32bit , comme OS windows 8

Non, Qt n'est pas un IDE (Integrated Development Environment ou Environnement de Développement intégré, si tu préfères :D), mais un framework (ou, si tu préfères, un ensemble de bibliothèques qui fonctionnent bien ensemble) qui était à la base une unique bibliothèque orientée vers la création d'IHM ;).

Par contre, ton IDE a de fortes chances d'être qtcreator, non :question:

Tu pourrais également utiliser code::blocks, mais le choix de qtcreator semble "logique" étant donné la configuration actuelle :D

Citation:

je me suis cassé la téte pour retrouver include qui contient console , ou src qui contient console.cpp

est ce que vous avez une idée

Des idées, je n'en manque pas... Mais il y a peu de chance qu'elles te soient d'un quelconque secours ;)

Par contre, je peux te donner quelques pistes ;)

Les projets Qt sont généralement gérés au départ d'un fichier dont l'extension est .pro (et dont le nom correspond généralement au nom du projet en cours, comme par exemple new_project.pro ) et qui devrait apparaitre dans la vue "projets" de qtcreator.

C'est un simple fichier texte qui reprend l'ensemble des réglages pour mener la compilation à son terme.

Si tu double cliques sur ce fichier, qtcreator te l'ouvrira et te permettra d'en voir le contenu ;)

Dans ce fichier, tu devrais avoir deux variables nommées respectivement HEADERS, qui reprend la liste des fichiers d'en-tête que tu as rajoutés à ton projet et la variable SOURCES qui reprend la liste des fichiers d'implémentation (*.cpp) que tu as rajouté à ton projet.

Ces listes utilisent les chemins relatifs qui permettent, au départ du fichier .pro, d'accéder aux différents fichier.

Tu devrais donc avoir quelque chose qui pourrait ressembler à
Code:

1 2 3 4 5 6 SOURCES += src/Console.cpp \ # ...(autres fichiers d'implémentation) src/main.cpp INCLUDES += include/Console.hpp \ # ...(autres fichiers d'en-tête)
Si c'est le cas, tu peux rajouter le dossier qui contient les fichiers d'en-tête (ici, c'est juste include) à la variable INCLUDEPATH sous la forme de

Code:

INCLUDEPATH += include

Evidemment, les éventuels dossiers qui pourraient se trouver à gauche de include ont toute leur importance ;)

Par exemple, je suis actuellement sur un projet dans lequel les différentes variables sont déclarées sous la forme de
Code:

1 2 3 4 5 6 7 8 9 INCLUDEPATH += ../../ebnf/include SOURCES += \ ../../ebnf/src/BnfNode.cpp \ # d'autres fichiers d'implémentation HEADERS += \ # remarque que ../../ebnf/include correspond valeur définie pour # la varariable INCLUDEPATH ../../ebnf/include/BnfNode.h \ #d'autres fichiers d'en-tête
Si tu as laissé qtcreator créer ton projet dans le chemin par défaut, il y a de fortes chances que ton projet se trouve dans ton dossier "documents", dans un sous dossier portant le nom du projet lui-même. (typiquement dans c:\Utilisateurs\<ton nom>\Document\<nom du projet> ).

Si tu as sélectionné un autre dossier dans lequel générer ton projet, il t'appartient de savoir où tu as été le mettre :D

Notes enfin que, si tu n'as pas créé la classe Console, ou si tu n'as pas donné les noms corrects à tes fichiers, il y a peu de chances pour que le reste fonctionne ;)

Pourrais tu donc placer ici:

une copie du contenu de ton fichier .pro
une copie des différents fichiers de ton projet.
A mon avis, tu as "simplement" fait une erreur dans les différents noms de tes fichiers :D

03/11/2013, 03h29
solitrion

:D
bon pour le fichier .pro voici son contenu :
TEMPLATE = app
CONFIG += console
CONFIG -= app_bundle
CONFIG -= qt

SOURCES += main.cpp

HEADERS += \
fonction.h

et pour la suite qu'est ce que tu veux dire par une copie des fichiers de ton projets , leurs contenu ?
03/11/2013, 03h46
koala01

Citation:

Envoyé par solitrion

:D
bon pour le fichier .pro voici son contenu :
TEMPLATE = app
CONFIG += console
CONFIG -= app_bundle
CONFIG -= qt

SOURCES += main.cpp

HEADERS += \
fonction.h

et pour la suite qu'est ce que tu veux dire par une copie des fichiers de ton projets , leurs contenu ?

Oui, j'aimerais beaucoup voir le contenu de fonction.h et de main.cpp :D.

Il faut comprendre que je suis peut etre à quelques centaines de kilomètres de toi (ou peut être à moins de cent mètres, qui sait :D), et que ma dernière boule de crystal est malheureusement tombée en panne hier soir.

Si je peux tirer certaines conclusion "par habitude", je ne peux malheureusement t'aider qu'à condition d'avoir une idée bien précise de l'état de ton projet. Et pour ce faire, je ne peux me reposer que sur toi.

La règle de base d'un forum est finalement toute simple : aide nous à t'aider si tu veux obtenir une réponse efficace ;)

Autrement dit, plus tu pourras donner d'informations utiles pour résoudre ton problème, plus tu auras de chances d'obtenir rapidement une solution efficace ;)

je comprend bien et merci infiniment

je n'ai pas encore bien avancée dans la programmation puisque dés le départ je ne pouvait pas inclure des lib

fonction.h :

Code:

1
2
3
4
5
6
7
8
9
10
11
#ifndef FONCTION_H
#define FONCTION_H
class Mine
{private:
    int n;
    int * p;
public:
    Mine():n(0){p=new int[50];};
    ~Mine(){};//destructeur
};
#endif // FONCTION_H

tp2 :

Code:

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
31
32
#include <iostream>
#include <fonction.h>
#include <windows.h>
#include <cstdlib>
#include <Console.h>
 
 
 
 
using namespace std;
void menu()
 
{  int i=1;
  do
 {
  cout<<"Welcome";
   Sleep(1000);
   Clear();
i++;}
while (i<4)
   }
 
int main()
{
 
 
 
    menu();
 
    cout << "Hello World!" << endl;
    return 0;
}

03/11/2013, 05h51
koala01
Une petite remarque générale avant de commencer (qui t'évitera de te faire taper sur les doigts par la suite :D) : On demande avec insistance aux gens d'entourer le code qu'ils présentent des balises [ CODE ] le code vient ici [ / CODE ]. Cela peut se faire en sélectionnant le code et en cliquant sur le bouton # qui se trouve en haut du formulaire.

Cela permet d'avoir une meilleure mise en forme et de profiter d'une coloration syntaxique qui facilite la lecture à tout le monde :D

Ensuite, je ne résiste pas à l'envie de te faire une autre remarque, "organisationnelle" celle là:
Il est "de coutume" de placer les classes que l'on crée dans des fichiers dont le nom correspond à celui de la classe en question.

Cela ne change rien au niveau du compilateur (ton fichier "fonction.h" aurait tout aussi bien pu s'appeler "tratanpion.h", le compilateur n'en aurait pas eu grand chose à y redire :D) mais cela permet de s'y retrouver beaucoup plus facilement quand le projet prend de l'envergure.

Ainsi, la définition de ta classe Mine serait beaucoup mieux placée dans un fichier nommé... Mine.h, et l'implémentation de ses fonctions membres prendrait avantageusement place dans un fichier nommé ... Mine.cpp.

Ce n'est bien sur qu'un détail, mais tu ne tarderas pas à te rendre compte qu'il facilite énormément la vie :D

Pour en terminer avec ta classe Mine, je ne peux pas me résoudre à faire deux remarques supplémentaires :

La première, c'est que, comme tu as recours à l'allocation dynamique de la mémoire pour p (qui, au passage, mériterait grandement d'être renommé afin d'exprimer clairement son utilisation :aie:) au travers de new int[50], tu dois prévoir que le destructeur libère cette mémoire en invoquant delete [] p afin d'éviter les fuites mémoires.

Et, du coup, tu devrais appliquer la grande règle des trois :

Citation:

Si, parmi les trois fonctions que sont le constructeur de copie, l'opérateur d'affectation et le destructeur, tu en viens à décider de fournir l'implémentation d'une de ces fonctions, il faudra alors envisager de fournir l'implémentation des trois autres.

C'est un sujet relativement récurrent sur le forum. Une petite recherche des termes "forme canonique (orthodoxe) de coplien" ou "règle des trois grands" devrait te donner quelques résultats intéressants ;)

La deuxième remarque concerne le nom que tu as donné à ta classe:

Si l'on ne se base que sur le nom, on a l'impression que cette classe est sensée représenter une mine, alors qu'elle représente en réalité un champs de mines (ou peut être une liste quelconque de mines).

Il est particulièrement important de veiller à ce que les différents noms que tu donnes à tes classes, à tes fonctions et à tes variables permettent à celui qui lira ton code de se faire une idée très précise et "non ambigüe" de ce à quoi elles servent.

Cela n'a l'air de rien, mais le simple fait d'avoir directement une idée précise de ce qu'est sensé faire une fonction ou représenter un type défini par l'utilisateur facilite énormément la compréhension générale du code que l'on est occupé à lire.

Et tu ne tarderas pas à te rendre compte qu'une excellente compréhension du code est essentielle pour la suite, entre autres, pour débusquer les différentes erreurs ;)
J'en arrive maintenant à ton fichier main.cpp.

La première question que j'ai envie de poser est : d'où vient ce code :question:

De toutes évidences, tu as peut être un peu modifié le code en question, mais je suis près à parier ma chemise que tu as fait un gros copier / coller du fichier main.cpp de ton TP1 avant de commencer à le modifier.

Me trompes-je :question:

D'ailleurs, je serais également prêt à parier ma chemise sur le fait que, si ta classe (mal nommée :D) Mine se trouve dans le fichier fonction.h, c'est parce que tu as peut être bien repris une grosse partie de TP1, non :question:

Saches que je ne te juge absolument pas, que le copier / coller (ou la copie de fichiers) est une pratique courante en développement.

Mais le fait est que c'est souvent une pratique dangereuse :aie:

Ainsi, il semblerait que le projet d'origine (TP1 :question:) ait défini une classe Console, dans un fichier d'en-tête nommé Console.h.

Le fait d'avoir "bêtement" copié le fichier main.cpp t'a fait "oublier" de copier le fichier Console.h qui, en l'occurrence, n'a sans doute pas grand chose à faire dans ton projet TP2 :aie:

Il y a donc deux solutions :

Soit tu n'as purement et simplement pas besoin de la classe Console ( et je ne vois rien dans le code qui tendrait à démontrer que tu en as besoin) et tu peux donc supprimer l'inclusion du fichier d'en-tête sans te poser trop de question.

Soit tu as réellement besoin de cette classe, et, dans ce cas, deux as de nouveau deux solutions:

La plus facile (celle dont j'espère pour toi qu'elle s'avérera correcte) est que Console.h fait partie d'une bibliothèque externe qui était utilisée par TP1.

Dans ce cas, il te "suffira" d'arriver à localiser les fichiers d'en-tête de cette bibliothèque ainsi que la bibliothèque elle-même (libXXX.a où XXX correspond au nom de la bibliothèque) et de rajouter les options "qui vont bien" dans ton fichier .pro.

La dernière solution sera beaucoup moins sympa car elle risque de demander beaucoup plus de travail (ou non, en fonction de différentes choses).

Pour que ton projet actuel puisse fonctionner, il faudra copier au minimum le fichier Console.h (et le fichier Console.cpp, s'il existe) du TP précédant ainsi que tous les fichiers d'en-tête ( *.h ou *.hpp) "personnels" qui pourraient être inclus par ces deux fichier, et tous les fichiers d'implémentation (*.cpp) relatifs au fichiers d'en-tête en question.

Il faudra ensuite rajouter tous ces fichiers à ton projet actuels (typiquement, les fichier *.h / *.hpp à la variable HEADERS et les fichiers *.cpp correspondants à la variable SOURCES ).

Ceci dit, je ne peux décidément pas laisser sous silence quelques remarques supplémentaires au sujet du contenu de ton fichier main.cpp.

La première est que tu devrais -- vraiment -- essayer d'appliquer des règles d'indentations et de mise en forme strictes.

Les règles communément admises à ce niveau là sont:
- une déclaration ou une instruction par ligne
- un niveau d'indentation par paire d'accolade "{ }" (généralement, j'utilise 4 espaces, mais certains préfèrent en utiliser 3 et d'autres montent à 8... Le principal est surtout d'appliquer les mêmes règles d'indentation tout au long du projet ;))
En respectant ces règles particulièrement simple, on modifierait avantageusement le code de ta fonction menu en
Code:

1 2 3 4 5 6 7 8 9 void menu() { int i=1; do { cout<<"Welcome"; Sleep(1000); Clear(); i++; }while (i<4) }
Et, du coup, on remarquerait "tout de suite" (enfin, avec un peu d'habitude de la syntaxe propre au C++ quand même) que tu n'a pas bien respecté la syntaxe de la boucle do... while.

A moins qu'il ne s'agisse d'une copier /coller foireux, il faut un point virgule ";" après l'accolade fermante du while lorsque tu écris une boucle do... while.

Le code correct sera donc
Code:

1 2 3 4 5 6 7 8 9 void menu() { int i=1; do { cout<<"Welcome"; Sleep(1000); Clear(); i++; }while (i<4); // un ; doit venir après (i<4) :D }
Quand je te disais plus haut que la facilité de lecture du code est une composante essentielle de la facilité avec laquelle tu arriveras à débusquer les différentes erreurs! En voici la preuve.

Le langage en lui-même n'a strictement rien à faire des différents noms et de la "mise en forme" que tu peux donner à ton code (j'en ai vu certains qui s'amusaient à donner la forme des aliens de "space invaders" à leur code, même si ce n'était pas du C++ :D), mais il faut toujours garder à l'esprit que tu écris bien plus ton code pour un éventuel relecteur que pour le compilateur.

Le relecteur, cela peut être toi, aujourd'hui, demain ou... dans six mois ou un an.

Tant que ton code est "tout frais dans ta mémoire", il te paraitra toujours d'une limpidité incroyable.

Le problème, c'est que si tu viens à le relire dans six mois ou un an, alors que tu as peut être écrit plusieurs milliers de lignes de code depuis et que tu as, surtout, eu plus que largement le temps d'oublier une partie de ce qu'était sensé faire ton code, si tu n'a pas veillé à ce que le code soit facilement compréhensible en "première lecture", tu comprendras rapidement ta douleur :D

Tout ce qui pourra faciliter la relecture te facilitera la vie de développeur:
1. Le fait de choisir des noms explicites (qui "auto commentent" la raison d'être d'une variable, d'un type ou d'une fonction)
2. Le fait de veiller à n'avoir qu'une instruction (ou une déclaration de variable) par ligne
3. Le fait de respecter des règles d'indentation strictes
4. Le fait de respecter les mêmes règles de nommage et de codage au travers de tout le projet
sont autant de points qui te faciliteront la (re)lecture de ton code, et donc la vie si tu dois un jour revenir sur du code que tu as eu largement le temps d'oublier depuis que tu l'as écrit.

Je ne cherche pas à t'imposer un style de mise en forme particulier, un nombre d'espaces pour l'indentation spécifique ou des règles de nommage particulières.

Je cherche juste à te convaincre que, quels que puissent être le "style de codage" ou les règles de nommages que tu utiliseras, il faut impérativement qu'ils soient cohérents et appliqués à l'ensemble de ton projet ;)
03/11/2013, 09h02
minnesota

salut,

moi aussi je ne peux pas me résoudre à faire une remarque supplémentaire koala01 :

tu as parié deux fois ta chemise :aie:
04/11/2013, 16h32
Médinoc

Je suis prêt à parier que la classe Console mentionnée dans le message de départ, qui expose une méthode statique SetWindowSize(), est la classe System::Console du Framework .Net. Elle n'est pas utilisable en C++ normal.
04/11/2013, 19h38
minnesota

Salut,

Est-ce qu'elle est bien cette classe Médinoc ? Est-ce que tu la trouves bien faite ? Désolé pour ce petit HS.
04/11/2013, 21h33
Médinoc

Dans une application .Net en mode console, elle gère plutôt pas mal. Mais je dois avouer que je n'ai encore jamais tenté d'aller loin avec (genre, refaire de la Text User Interface comme j'en avais l'habitude sous DOS), jusqu'ici je ne m'en suis servi que pour donner un peu de couleur à mon texte...
04/11/2013, 21h45
minnesota

Comme t'as pu le deviner, c'était pour savoir si elle pouvait servir de base comme bon candidat à un équivalent C++, y'a bien "curses/pdcurses", mais bon. Merci pour le retour ;)