#include emboité probleme

Version imprimable

27/06/2013, 17h13
gabrielS

#include emboité probleme
Bonjour tout le monde.

J'ai un soucis de #include qui commence a me faire tomber les cheveux (a force de tirer dessus d'enervement.. ).

Le probleme est assez "simple" tout du moins a expliquer : voila le soucis :
J'ai mon main qui include le fichier "Simu.hpp".
Ce dernier include 4 differents fichiers ObjectComplex.hpp, IO.hpp et GUI.hpp et handleWindow.hpp

ObjectComplex.hpp include lui-meme 3 ficihiers ObjetSimple (Resistor, Capacitor, Electrode.hpp) qui chacun include "ElectricComponent.hpp" : ce dernier include <math.h> et algorithm.hpp

IO.hpp include "Current.hpp", "PS.hpp" et Voltage.hpp ; ces derniers uncludant a eux tous "algorithm.hpp" et <string> et <iostream>

Enfin, GUI.hpp include 3 boutons (pour gerer les InputOutput : CurrentButton.hpp, VoltageButton.hpp et PSButton.hpp) qui chacun include "algorithm.hpp" et <math.h>, et egalement la librairie que j'utilise (SFML).

Jusque la, aucun probleme, ca compile bien etc..
Le probleme vient maintenant : je cherche a implementer dans "algorithm.cpp" une fonction qui prend en entrée une Simu (car faisant des calculs a la fois sur IO, et ObjectComplex). De facon 'naturelle' (selon moi tout du moins =p), j'include donc Simu.hpp dans "algorithm.hpp" - et la .... tout crash a la compil : je recois des centaines d'erreur

Voila, je pourrais creer la fonction qui m interesse (ce que j ai d'ailleurs fait pour le moment) dans Simu, mais cette fonction est purement algorithmique, elle se sert juste de plusieurs data pour ne rien modifier mais juste retourner un 'double' qui m'interesse (d'ou ma volonté de mettre cette fonction dans algo).

Les messages d'erreur ressemblent a peu pres tous a ca :
Code:

1 2 error C2061: syntax error : identifier 'InputOutput' error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
( la deuxieme erreur découle de la premiere je suppose .. )
Juste pour preciser, tout mes .hpp sont sous la forme
Code:

1 2 3 4 #ifndef TOTO_H #define TOTO_H // here #include.hpp and function signatures #endif
27/06/2013, 17h17
Astraya

Aurais-tu des dépendances cycliques?
A demandant B et B demandant A? Dans ce cas il faut que tu fasses une forward declaration.

EDIT: Si tu utilises des pointeurs en paramètre ou fonction membre. N'inclus jamais tes .h mais fais une forward declaration, ca te permet deux choses : ne pas avoir de problème de dépendances et accélérer la compilation (inclus iostream ou windows.h pour voir la différence... :) )
27/06/2013, 19h37
gabrielS
J'ai en effet des dependances cycliques. Simu a besoin de fonctionnalites de algo et algo a besoin de connaitre le type Simu.

Je vais me renseigner sur "forward declaration" ..
Merci Astraya

Edit : Simple constatation sur mon code (mais je comprends vraiment pas du tout d'ou ca vient - j'essaie de debugger les #include en step by step, et mon programme compile lorsque je fais ca :
Code:

1 2 3 #include "current.hpp" #include "power_supply.hpp" #include "voltage.hpp"
dans "algo.hpp" et ne compile PAS lorsque je fais ca :

Code:

#include "input_output.hpp"

alors que input_output.hpp ressemble a ceci :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 #ifndef INPUT_OUTPUT_H_ #define INPUT_OUTPUT_H_ #include "current.hpp" #include "power_supply.hpp" #include "voltage.hpp" class InputOutput { // CODE class }; #endif
Quelqu'un a une explication ?
27/06/2013, 21h42
Astraya

Donnes toujours les d'erreurs lorsque tu dis que cela ne compile pas s'il te plait. un simple copier coller fera l'affaire :)

Merci
28/06/2013, 15h23
gabrielS
Ce sont toujours les memes messages d'erreur i.e.
Code:

1 2 3 error C2061: syntax error : identifier 'Current' error C2143: syntax error : missing ';' before '&' error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
le "missing ;" marche tres bien lorsque je mets pas #include "input_output.hpp" mais les 3 include comme expliques precedemment.

Je sais pas d'ou ca vient, j'essaie de tout passer en forward declaration.
A ce propos, l'exemple ici est-il bien ?
Je trouve ca plutot moche de mettre tous les .h dans le .cpp ..

Edit : parler de moche/beau parle (of course =p) de clarté du code et non de stylisme artistico-graphique =)
28/06/2013, 15h31
Astraya

Bonjour,

a ce que je vois c'est toujours un problème de déclaration. Ça dois être un vrai bord*l :aie:

Citation:

Je trouve ca plutot moche de mettre tous les .h dans le .cpp ..

En quoi c'est moche? nous ne faisons pas de la peinture mais de la programmation. Dans un .cpp tu n'as pas de problème de loop dans les includes, tu accélères ta compilation. Bref, dire que c'est pas beau est un argument qui n'a rien a faire en programmation ^^
As-tu forward ta classe Current? car il semble que son include ne soit pas pris en compte.
28/06/2013, 16h12
therwald

Citation:

Envoyé par Astraya

Bref, dire que c'est pas beau est un argument qui n'a rien a faire en programmation ^^

Ça se discute, car "beau" ou "moche" est employé par pas mal de personnes (le PO semble être plus ou moins consciemment dans ce cas) comme synonyme de clair, lisible, ou standard.
Et là ça peut être très important car la programmation est pour beaucoup de gens une activité d'équipe dans laquelle la clarté de lecture et la facilité de compréhension (donc aussi les standards) joue un rôle important (et quand on est seul on peut aussi se provoquer une consommation frénétique d'aspirine en faisant un code trop embrouillé ou trop chargé en bidouille...)

Ici, par contre, je te rejoins sur le fait que retarder au maximum l'utilisation d'un header (donc au final le plus souvent possible ne le mettre d'include que dans les cpp) est une bonne chose: vitesse de compilation, certes, mais aussi moins d'effets de bords, y compris moins de risque d'impacts en modifiant le header...
28/06/2013, 16h45
Astraya

@therwald :
héhé bien sur je ne parlais pas de lisibilité quand je parlais de beauté. Mais je parlais plus de beauté dans le style : "Je trouve pas que la couleur bleu des includes et les #includes au début rendent mon fichier joli".
Après certains effets de style ( indentation, nomenclature, commentaire au bon endroit par exemple ) ne rendent pas plus performant la compilation mais par contre rend plus performant le développeur ^^
cf: http://cpp.developpez.com/cours/cpp/?page=page_9
28/06/2013, 17h59
gabrielS

Citation:

A ce propos, l'exemple ici est-il bien ?

Donc l'exemple donne ici est "propre" (et non beau, j'essaierai de dire propre plutot que beau, dans le sens lisible =) )
29/06/2013, 00h33
therwald

Oui, il est propre. En plus d'être lisible, il a deux caractéristiques importantes:
1) le fait de ne pas inclure inutilement des headers dans les headers évite un cycle d'inclusion avec la dépendance croisée.
2) du fait que les headers utilisent la forward declaration, les détails de A ne sont pas propagés aux fichiers qui incluent B.h, et les détails de B ne sont pas propagés aux fichiers qui incluent A.h Cela a pour effet d'accélérer la (re)compilation, mais dans certains cas cela permet aussi de limiter le couplage (c''est à dire que si le code client utilise juste comme paramètre des instances de B fournies par appel à A, il n'a pas besoin de connaître les détails de B, ce qui veut dire qu'il n'y aura pas besoin de modifier le code appelant A en cas de modification de B. Cela participe à la modularité du code.